Kernel trace Windows 7 WinDbg

I'm getting no debug information when debugging en_windows_7_checked_build_dvd_x86_398742. I can't see even my own trace info (ATLTRACE). In opposite, Windows XP Checked works like a charm. I get "Bad QueryIdType:5" msg on debug session start with Windows 7. 开发者_如何学GoKernel debug is set up properly obviously. Please help...

I was able to fix it from within windbg, on windows 7 32 bit:

ed Kd_DEFAULT_Mask 8

According to the msdn article, you can also use the registry, but you must reboot for it to take effect. Create a DWORD key under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter called DEFAULT with a value of 8.

The up to date microsoft documentation is available here: http://msdn.microsoft.com/en-us/library/windows/hardware/ff551519(v=vs.85).aspx

OK, i found the solution here. It may help people:

The problem: Your DbgPrint or KdPrint messages don't appear in WinDbg (or KD) when you run your driver on Windows Vista.

The reason? Vista automatically maps DbgPrint and friends to DbgPrintEx. Now, you may recall that DbgPrintEx allows you to control the conditions under which messages will be sent to the kernel debugger by filtering messages via a component name and level in the function call and an associated filter mask in either the registry or in memory.

In Vista, DbgPrint and KdPrint are mapped to component "DPFLTR_DEFAULT_ID" and level "DPFLTR_INFO_LEVEL". Of course, in Vista, xxx_INFO_LEVEL output is disabled by default. So, by default, your DbgPrint/KdPrint doesn't get sent to the kernel debugger.

How to fix it? Two choices:

• Enable output of DbgPrint/KdPrint messages by default --Open the key HKLM\SYSTEM\CurrentControlSet\Session Manager\Debug Print Filter. Under this key, create a value with the name DEFAULT Set the value of this key equal to the DWORD value 8 to enable xxx_INFO_LEVEL output as well as xxx_ERROR_LEVEL output. Or try setting the mask to 0xF so you get all output. You must reboot for these changes to take effect.

• Specifically change the component filter mast for DPFLTR. In early releases of Vista/LH you changed the default printout mask by specifying a mask value for the DWORD at Kd_DPFLTR_MASK ("ed Kd_DPFLTR_MASK"). In build 5308 (the February CTP of Vista), it seems that the mask variable has changed and you need to set the mask value for the DWORD at Kd_DEFAULT_MASK ("ed Kd_DEFAULT_MASK). In either case, specify 8 to enable DPFLTR_INFO_LEVEL output in addition to DPFLTR_ERROR_LEVEL output, or 0xF to get all levels of output.

See the WDK documentation for Reading and Filtering Debugging Messages (follow the path: Driver Development Tools\Tools for Debugging Drivers\Using Debugging Code in a Driver\Debugging Code Overview) for the complete details on the use of DbgPrintEx/KdPrintEx. Or look at the Debugging Tools For Windows documentation (Appendix A) on DbgPrintEx.

For enabling output of DbgPrint/KdPrint messages by default the registry path is "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter" Session Manger ist below Control. The Default value normaly is 0xf. That enables all messages. To set a better fitting bitmask at your needs the informations are located at https://learn.microsoft.com/de-de/windows-hardware/drivers/devtest/reading-and-filtering-debugging-messages#identifying-the-component-name

If you take Visual Studio 2015 or 2017, the standard configuration won't set this flag by default. When start working with examples don't forget to set this extra on the Debug-Target.

So this helped me in my Windows 10 environment using Windbg.

A second problem was using devcon on Windows 10 like described in the echo example https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debug-universal-drivers---step-by-step-lab--echo-kernel-mode-#install

At Bullet "7 Locate the built driver files" transfering the needed driver files to the Debug-Target and load them with devcon. Using Windows 10 you also have to copy the catalog-File. Otherwise devcon.exe will fail as described. Of cause you will need to install the test-certificate as well. This is usually done when preparing the debugging environment with Visual Studio 2015/2017. Just double check with certmgr.