How to configure dbgPrintEx() to be disabled by default?

Does anyone know why nt!KD_DEFAULT_Mask is 0x3fffffff by default? I need to figure out how to configure dbgPrintEx() calls to be disabled by default.

I am working on a kernel level driver, specifically a DSM driver. I want to use DbgPrintEx to provide tracing ability. Specifically I want to be able to enable it on a production release. I want to be able to dynamically turn on traces to help debug on support calls or during problems are test group sees, without having to load a special build. By default I want the traces should to be disabled.

From the Googling and MS documentation I have read, my problem appears to be the opposite of most folks. My trace seems to be enabled and outputting messages in dbgview by default.

I have reproduced my problem on two different 2008R2 systems. The same certified DSM image/build runs on 2008, 2012, and 2012R2, so the final solution needs to work for all of those OS.

My code looks like:

#define DPFLTR_DSM_DRIVER_LEVEL DPFLTR_MASK | 0x10

DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_DSM_DRIVER_LEVEL, “[DSM_KM] BestAdminPath: returning READY device\n”);

I have also tried changing the level values in my source code to use DPFLTR_MASK|0x10, DPFLTR_TRACE_LEVEL, DPFLTR_INFO_LEVEL, and the value 7. In all cases, my trace statements appear in dbgview.

My registry does not even have a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter key. I also tried creating the key and creating DEFAULT, IHVAUDIO, IHVDRIVER, and SR entries using the OSR SetDbgPrintFiltering.exe tool. I tried those entries with values of both 0x0, and 0x1. I did remember to reboot, to allow the values to take and again, the messages always came out in dbgview.

I tried using the kernel debug to look at the masks, for example, I did a “dd nt!Kd_WIN2000_Mask”. Here is what I got for all of them:
lkd> dd nt!Kd_WIN2000_Mask
fffff80001c55fb0 00000001 lkd\> dd nt!Kd_DEFAULT_Mask fffff80001c6deb0 3fffffff
lkd> dd nt!Kd_IHVDRIVER_Mask
fffff80001c6de50 3fffffff lkd\> dd nt!Kd_IHVAUDIO_Mask fffff80001c6de58 3fffffff
lkd> dd nt!Kd_SR_Mask
fffff800`01c6de48 3fffffff
The following appears to toggle my dbg print statements, when using DPFLTR_MASK | 0x10 for the level, off then on again:

lkd> ed nt!Kd_IHVDRIVER_Mask 0x1
lkd> ed nt!Kd_IHVDRIVER_Mask 0x3fffffff

So, when I change the default value of nt!Kd_IHVDRIVER_Mask from 0x3fffffff to 0x1, my statements stop. Therefore, I think the default value of the nt!Kd_IHVDRIVER_Mask is the issue. Does anyone know why the Mask coming up as 0x3fffffff and how can I code my dbgPrintEx() calls so they are disabled by default, but able to be turned on in a released version of my driver.

Thanks,
Curtis

In this scenario, you typically use WPP, not DbgPrint(Ex). WPP was intended to be always present in the code, only logging when enabled by a listener. Your WPP trace will also not be polluted by anyone else using DbgPrint or WPP, it is your own channel

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Lehman, Curtis (LeftHand Networks, Boulder CO)
Sent: Thursday, September 12, 2013 11:39 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] How to configure dbgPrintEx() to be disabled by default?

Does anyone know why nt!KD_DEFAULT_Mask is 0x3fffffff by default? I need to figure out how to configure dbgPrintEx() calls to be disabled by default.

I am working on a kernel level driver, specifically a DSM driver. I want to use DbgPrintEx to provide tracing ability. Specifically I want to be able to enable it on a production release. I want to be able to dynamically turn on traces to help debug on support calls or during problems are test group sees, without having to load a special build. By default I want the traces should to be disabled.

From the Googling and MS documentation I have read, my problem appears to be the opposite of most folks. My trace seems to be enabled and outputting messages in dbgview by default.

I have reproduced my problem on two different 2008R2 systems. The same certified DSM image/build runs on 2008, 2012, and 2012R2, so the final solution needs to work for all of those OS.

My code looks like:

#define DPFLTR_DSM_DRIVER_LEVEL DPFLTR_MASK | 0x10

DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_DSM_DRIVER_LEVEL, “[DSM_KM] BestAdminPath: returning READY device\n”);

I have also tried changing the level values in my source code to use DPFLTR_MASK|0x10, DPFLTR_TRACE_LEVEL, DPFLTR_INFO_LEVEL, and the value 7. In all cases, my trace statements appear in dbgview.

My registry does not even have a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter key. I also tried creating the key and creating DEFAULT, IHVAUDIO, IHVDRIVER, and SR entries using the OSR SetDbgPrintFiltering.exe tool. I tried those entries with values of both 0x0, and 0x1. I did remember to reboot, to allow the values to take and again, the messages always came out in dbgview.

I tried using the kernel debug to look at the masks, for example, I did a “dd nt!Kd_WIN2000_Mask”. Here is what I got for all of them:
lkd> dd nt!Kd_WIN2000_Mask
fffff80001c55fb0 00000001 lkd\> dd nt!Kd_DEFAULT_Mask fffff80001c6deb0 3fffffff
lkd> dd nt!Kd_IHVDRIVER_Mask
fffff80001c6de50 3fffffff lkd\> dd nt!Kd_IHVAUDIO_Mask fffff80001c6de58 3fffffff
lkd> dd nt!Kd_SR_Mask
fffff800`01c6de48 3fffffff
The following appears to toggle my dbg print statements, when using DPFLTR_MASK | 0x10 for the level, off then on again:

lkd> ed nt!Kd_IHVDRIVER_Mask 0x1
lkd> ed nt!Kd_IHVDRIVER_Mask 0x3fffffff

So, when I change the default value of nt!Kd_IHVDRIVER_Mask from 0x3fffffff to 0x1, my statements stop. Therefore, I think the default value of the nt!Kd_IHVDRIVER_Mask is the issue. Does anyone know why the Mask coming up as 0x3fffffff and how can I code my dbgPrintEx() calls so they are disabled by default, but able to be turned on in a released version of my driver.

Thanks,
Curtis


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Hi Dd,

Thanks for the suggestion. I will continue to look at this approach, but initial looks leave me to believe this is missing one of the requirements I’m striving for. That is to avoid or minimize having to install additional software and tools in the system under test’s. This is especially true for issues involving customers at their locations.
With WPP, I would have to install tools like tracepdb, tracelog, and tracefmt. The initial MS documentation, depending on the tool, mentions things like having to make sure the systems under test have the latest dlls and permissions to use them.

I would still like to try and get the dbgPrintEx approach working if possible. One of my other reasons is that part of my DSM driver also has an application portion to it. It already has legacy tracing ability. The tracing in the application portion works a lot like the dbgPrintEx approach. It’s enabled and disabled through some registry settings and the output goes to dbgview. Therefore, my test group is already trained on both how to edit the registry and use dbgView as well as having the ability to consolidate all the trace messages from both parts of the driver in one tool.

Any thoughts on how to get dbgPrintEx functions to work so they are disabled by default and yet able to be turned on in a release build?

Thanks,
Curt

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Thursday, September 12, 2013 1:54 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to configure dbgPrintEx() to be disabled by default?

In this scenario, you typically use WPP, not DbgPrint(Ex). WPP was intended to be always present in the code, only logging when enabled by a listener. Your WPP trace will also not be polluted by anyone else using DbgPrint or WPP, it is your own channel

d

I agree with Doron. What you’ve described is a perfect scenario for WPP. Heck even WE here at OSR – no friends of WPP for sure – have decided to use WPP for this exact purpose in our newest products.

In terms of getting DbgPrint to be off by default… You just write some code. Instead of using DbgPrint in your code you use MyDbgPrint. In your MyDbgPrint function you check a flag in a global variable in your driver that indicates whether debugging output should be produced or not and if output IS enabled, you call DbgPrint… if it’s NOT enabled you just return. You set the controlling global flag either (a) using the debugger, or (b) via an entry in the Registry during one of your driver’s initialization routines.

Does that answer your question?

Now… seriously. Go back and re-consider using WPP. It’s what you want to use in this situation. Really. It doesn’t slow down your driver as much as DbgPrint, it doesn’t expose your IP (by way of human readable DbgPrint messages) to your customers, and it produces a nice, compact, trace file.

Peter
OSR

>tracing ability. Specifically I want to be able to enable it on a production release.

PLEASE DON’T.

Use WPP/ETW or Windows event log (turnable on by some registry value).


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

And use logman, inbox, instead of tracelog.

~kenny

From: Maxim S. Shatskihmailto:xxxxx
Sent: ?Friday?, ?September? ?13?, ?2013 ?3?:?03? ?PM
To: Windows System Software Devs Interest Listmailto:xxxxx

>tracing ability. Specifically I want to be able to enable it on a production release.

PLEASE DON’T.

Use WPP/ETW or Windows event log (turnable on by some registry value).


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

Note that the state of the event log is not under your control. There are
many ways to configure it, such as “purge oldest” or “refuse newest”, and
the size of the event log, are all under control of the end user or the
sysadmin at the end user site. So the role of the event log is to record
events that indicate either transient or permanent malfunction of your
device, so the sysadmin can read them, and your tech support can ask the
user/sysadmin to read them, or, if your website supports active server
pages, having the user double-click on the URL in your MessageTable entry,
which sends the log information up and allows you to give a “smart”
response to the particular problem (e.g., “This was fixed in release m.n,
please update your driver”). It is a pretty lousy way to do “debug
print”. DbgPrint is the assembly-code of debugging output; the various
suggests here are for the “high-level” interfaces for logging and
debugging.
joe

And use logman, inbox, instead of tracelog.

~kenny

From: Maxim S. Shatskihmailto:xxxxx
> Sent: ýFridayý, ýSeptemberý ý13ý, ý2013 ý3ý:ý03ý ýPM
> To: Windows System Software Devs Interest Listmailto:xxxxx
>
>>tracing ability. Specifically I want to be able to enable it on a
>> production release.
>
> PLEASE DON’T.
>
> Use WPP/ETW or Windows event log (turnable on by some registry value).
>
> –
> Maxim S. Shatskih
> Microsoft MVP on File System And Storage
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

Yes, thanks this does answer my questions. Thanks everyone for the answers and suggestions.

I will need to investigate further into WPP, but it does look like a better long term solution. I can use the wrapper approach as a short term fix.

l wish I could have figured out why the default mask value for nt!Kd_IHVDRIVER_Mask was 0x3fffffff, and if that was a bug on my end or MS.

Thanks,
Curt

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Friday, September 13, 2013 8:54 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to configure dbgPrintEx() to be disabled by default?

I agree with Doron. What you’ve described is a perfect scenario for WPP. Heck even WE here at OSR – no friends of WPP for sure – have decided to use WPP for this exact purpose in our newest products.

In terms of getting DbgPrint to be off by default… You just write some code. Instead of using DbgPrint in your code you use MyDbgPrint. In your MyDbgPrint function you check a flag in a global variable in your driver that indicates whether debugging output should be produced or not and if output IS enabled, you call DbgPrint… if it’s NOT enabled you just return. You set the controlling global flag either (a) using the debugger, or (b) via an entry in the Registry during one of your driver’s initialization routines.

Does that answer your question?

Now… seriously. Go back and re-consider using WPP. It’s what you want to use in this situation. Really. It doesn’t slow down your driver as much as DbgPrint, it doesn’t expose your IP (by way of human readable DbgPrint messages) to your customers, and it produces a nice, compact, trace file.

Peter
OSR


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

One last update. I discovered what was changing all of the nt!Kd_*_Mask settings. If you use debugview tool, and select Capture->Enable Verbose Kernel Output, it changes all the mask values to 0x3fffffff.

Thanks again for all the help and input.
Curt

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Lehman, Curtis (LeftHand Networks, Boulder CO)
Sent: Tuesday, September 17, 2013 10:50 AM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] How to configure dbgPrintEx() to be disabled by default?

Yes, thanks this does answer my questions. Thanks everyone for the answers and suggestions.

I will need to investigate further into WPP, but it does look like a better long term solution. I can use the wrapper approach as a short term fix.

l wish I could have figured out why the default mask value for nt!Kd_IHVDRIVER_Mask was 0x3fffffff, and if that was a bug on my end or MS.

Thanks,
Curt

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Friday, September 13, 2013 8:54 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to configure dbgPrintEx() to be disabled by default?

I agree with Doron. What you’ve described is a perfect scenario for WPP. Heck even WE here at OSR – no friends of WPP for sure – have decided to use WPP for this exact purpose in our newest products.

In terms of getting DbgPrint to be off by default… You just write some code. Instead of using DbgPrint in your code you use MyDbgPrint. In your MyDbgPrint function you check a flag in a global variable in your driver that indicates whether debugging output should be produced or not and if output IS enabled, you call DbgPrint… if it’s NOT enabled you just return. You set the controlling global flag either (a) using the debugger, or (b) via an entry in the Registry during one of your driver’s initialization routines.

Does that answer your question?

Now… seriously. Go back and re-consider using WPP. It’s what you want to use in this situation. Really. It doesn’t slow down your driver as much as DbgPrint, it doesn’t expose your IP (by way of human readable DbgPrint messages) to your customers, and it produces a nice, compact, trace file.

Peter
OSR


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer