No user mode debug prints seen on Win7, in a kernel mode debug session.

Hi,

The machine I am talking about here is a Win7 system.

I have an App, which uses, *OutputDebugStringW* for printing debug traces.
This app will be started when the system starts(when the user logs in)

I would use DbgView in general. But I have situation where something’s going
wrong when it is started with the system restart.

I need to see the debug traces. so DbgView can not be used in this case.

I tried hooking to the test machine using WinDbg from a different machine.
But I see no user mode debug prints/trances in the WinDbg.

What to do about this? Are there any registry settings I need to manipulate
to see Debug prints?

Please suggest.

Regards,
Madhusudhana

Is
http://www.osronline.com/article.cfm?id=295
relevant?
“Madhusudan Narayan” wrote in message news:xxxxx@windbg…
Hi,

The machine I am talking about here is a Win7 system.

I have an App, which uses, OutputDebugStringW for printing debug traces. This app will be started when the system starts(when the user logs in)

I would use DbgView in general. But I have situation where something’s going wrong when it is started with the system restart.

I need to see the debug traces. so DbgView can not be used in this case.

I tried hooking to the test machine using WinDbg from a different machine. But I see no user mode debug prints/trances in the WinDbg.

What to do about this? Are there any registry settings I need to manipulate to see Debug prints?

Please suggest.

Regards,
Madhusudhana

At what point in the restart cycle are you?

mm

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Madhusudan Narayan
Sent: Thursday, July 29, 2010 8:23 AM
To: Kernel Debugging Interest List
Subject: [windbg] No user mode debug prints seen on Win7, in a kernel mode
debug session.

Hi,

The machine I am talking about here is a Win7 system.

I have an App, which uses, OutputDebugStringW for printing debug traces.
This app will be started when the system starts(when the user logs in)

I would use DbgView in general. But I have situation where something’s going
wrong when it is started with the system restart.

I need to see the debug traces. so DbgView can not be used in this case.

I tried hooking to the test machine using WinDbg from a different machine.
But I see no user mode debug prints/trances in the WinDbg.

What to do about this? Are there any registry settings I need to manipulate
to see Debug prints?

Please suggest.

Regards,
Madhusudhana — WINDBG is sponsored by OSR 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

“Rod Widdowson” wrote in message
news:xxxxx@windbg…
> Is
> http://www.osronline.com/article.cfm?id=295
> relevant?

In addition to the above - it is possible to call DbgPrintEx and its
friends from usermode.
Then you can specify explicit level and component.
To do so, use GetProcAddress from ntdll.dll.

Also, MSDN documentation on OutputDebugStringW says that it converts the
unicode string to ansi before calling DbgPrint. This can fail. Try
OutputDebugStringA.

Regards,
– pa

> “Madhusudan Narayan” wrote in message
> news:xxxxx@windbg…
> Hi,
>
> The machine I am talking about here is a Win7 system.
>
> I have an App, which uses, OutputDebugStringW for printing debug traces.
> This app will be started when the system starts(when the user logs in)
>
> I would use DbgView in general. But I have situation where something’s
> going wrong when it is started with the system restart.
>
> I need to see the debug traces. so DbgView can not be used in this case.
>
> I tried hooking to the test machine using WinDbg from a different
> machine. But I see no user mode debug prints/trances in the WinDbg.
>
> What to do about this? Are there any registry settings I need to
> manipulate to see Debug prints?
>
> Please suggest.
>
>
> Regards,
> Madhusudhana

First, if it is a console app, you should probably write to stderr instead
of using OutputDebugString. If it is a Windows app, you should be logging
things in a window, and forget you ever heard about OutputDebugString. You
can find a nice little class on my MVP Tips site, which I call the Logging
ListBox Control. I use it everywhere, and not once, in over 20 years of
Windows programming, have I ever called OutputDebugString for any purpose
whatsoever. Back in 1990, I decided this was a fundamentally losing
mechanism, and created my first logging listbox, which I did with an edit
control. Every beginner thinks the edit control is the right solution for
this problem, but it most decidedly is not; in fact, using an Edit control
is a poorer solution than OutputDebugString, which is already a very poor
solution. I learned, and well over 10 years ago, I released this control
for everyone to use. It is a very mature control, and the example shows how
to add “next error” and “previous error” buttons to your project and call
the interfaces. It can also save the log to a file, either at any time
(which assumes the app hasn’t crashed in some unrecoverable state) or
concurrent-with-logging, which means that the log file records events in
real-time (open, append, close, so it is always intact if your app
crashes)… It is a C++/MFC class, so if you are (shudder) programming in
raw Win32, you will have to adapt it to your environment. I have yet to
discover a reason to prefer raw Win32 API programming over MFC (I did it for
five years, discovered MFC, and never again wrote a raw Win32 API program).
You can learn MFC in two or three days, and it is worth the effort. (Oh
yes, it will take a couple years to master, but I get students building MFC
apps with 20 minutes of training when I teach the MFC course). MFC uses a
highly-stylized simple subset of C++, so you don’t need to learn C++ in all
its gloryXXXXXgory (I delivered my first C++ app in two weeks, never having
seen C++ in my life before that). If you want to program apps in native
code, learn MFC. The few days you spend doing this will pay back
tremendously in the years to come. Or learn WPF, or something like that.
But windowing apps built with the raw Win32 API are a waste of effort; you
can write then in a fraction of the time using MFC. And don’t try to tell
me that C programs in Win32 are “easier”; been there, done that, and they
most definitely are not!

My code is a free-use-for-whatever-purpose, and is NOT, repeat NOT, under
anything resembling the GNU license, so you are free to use it and you don’t
have to release your source.

It the event is a catastrophic failure, you probably want to write something
to the application log, anyway. You cannot expect your end users to know
how to set up to capture debug port output. So you should learn to write to
the event log from user space, which is a useful skill to know about. I can
even send an old (VS6) project I had that uses the mc compiler to create a
MESSAGETABLE resource; send me private email. But it is worth learning how
to use the even log. Note: this takes longer than learning how to use MFC.
And the payoff is high.

Essentially, if OutputDebugString did not exist, you would have to find a
reasonable way to report the error. So just pretend it doesn’t exist, and
proceed from there. No matter what solution you come up with, it will
certainly be better in every way from OutputDebugString (as long as you
don’t think an edit control is the solution!)

joe


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of M. M. O’Brien
Sent: Thursday, July 29, 2010 11:35 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] No user mode debug prints seen on Win7, in a kernel
mode debug session.

At what point in the restart cycle are you?

mm

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Madhusudan Narayan
Sent: Thursday, July 29, 2010 8:23 AM
To: Kernel Debugging Interest List
Subject: [windbg] No user mode debug prints seen on Win7, in a kernel mode
debug session.

Hi,

The machine I am talking about here is a Win7 system.

I have an App, which uses, OutputDebugStringW for printing debug traces.
This app will be started when the system starts(when the user logs in)

I would use DbgView in general. But I have situation where something’s going
wrong when it is started with the system restart.

I need to see the debug traces. so DbgView can not be used in this case.

I tried hooking to the test machine using WinDbg from a different machine.
But I see no user mode debug prints/trances in the WinDbg.

What to do about this? Are there any registry settings I need to manipulate
to see Debug prints?

Please suggest.

Regards,
Madhusudhana — WINDBG is sponsored by OSR 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


WINDBG is sponsored by OSR

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

This message has been scanned for viruses and
dangerous content by http:</http:> MailScanner, and is
believed to be clean.

Hmm. I have to take issue with the advice to not use the debugger for trace
statements. It’s where people expect to see them, and one day, you very
well might not be the one maintaining your code anymore.

Also, no matter what a license says, there are plenty of companies that
frown rather strongly on using code in this fashion. As in they fire you.

mm

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
Sent: Thursday, July 29, 2010 7:10 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] No user mode debug prints seen on Win7, in a kernel
mode debug session.

First, if it is a console app, you should probably write to stderr instead
of using OutputDebugString. If it is a Windows app, you should be logging
things in a window, and forget you ever heard about OutputDebugString. You
can find a nice little class on my MVP Tips site, which I call the Logging
ListBox Control. I use it everywhere, and not once, in over 20 years of
Windows programming, have I ever called OutputDebugString for any purpose
whatsoever. Back in 1990, I decided this was a fundamentally losing
mechanism, and created my first logging listbox, which I did with an edit
control. Every beginner thinks the edit control is the right solution for
this problem, but it most decidedly is not; in fact, using an Edit control
is a poorer solution than OutputDebugString, which is already a very poor
solution. I learned, and well over 10 years ago, I released this control
for everyone to use. It is a very mature control, and the example shows how
to add “next error” and “previous error” buttons to your project and call
the interfaces. It can also save the log to a file, either at any time
(which assumes the app hasn’t crashed in some unrecoverable state) or
concurrent-with-logging, which means that the log file records events in
real-time (open, append, close, so it is always intact if your app
crashes)… It is a C++/MFC class, so if you are (shudder) programming in
raw Win32, you will have to adapt it to your environment. I have yet to
discover a reason to prefer raw Win32 API programming over MFC (I did it for
five years, discovered MFC, and never again wrote a raw Win32 API program).
You can learn MFC in two or three days, and it is worth the effort. (Oh
yes, it will take a couple years to master, but I get students building MFC
apps with 20 minutes of training when I teach the MFC course). MFC uses a
highly-stylized simple subset of C++, so you don’t need to learn C++ in all
its gloryXXXXXgory (I delivered my first C++ app in two weeks, never having
seen C++ in my life before that). If you want to program apps in native
code, learn MFC. The few days you spend doing this will pay back
tremendously in the years to come. Or learn WPF, or something like that.
But windowing apps built with the raw Win32 API are a waste of effort; you
can write then in a fraction of the time using MFC. And don’t try to tell
me that C programs in Win32 are “easier”; been there, done that, and they
most definitely are not!

My code is a free-use-for-whatever-purpose, and is NOT, repeat NOT, under
anything resembling the GNU license, so you are free to use it and you don’t
have to release your source.

It the event is a catastrophic failure, you probably want to write something
to the application log, anyway. You cannot expect your end users to know
how to set up to capture debug port output. So you should learn to write to
the event log from user space, which is a useful skill to know about. I can
even send an old (VS6) project I had that uses the mc compiler to create a
MESSAGETABLE resource; send me private email. But it is worth learning how
to use the even log. Note: this takes longer than learning how to use MFC.
And the payoff is high.

Essentially, if OutputDebugString did not exist, you would have to find a
reasonable way to report the error. So just pretend it doesn’t exist, and
proceed from there. No matter what solution you come up with, it will
certainly be better in every way from OutputDebugString (as long as you
don’t think an edit control is the solution!)

joe


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of M. M. O’Brien
Sent: Thursday, July 29, 2010 11:35 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] No user mode debug prints seen on Win7, in a kernel
mode debug session.

At what point in the restart cycle are you?

mm

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Madhusudan Narayan
Sent: Thursday, July 29, 2010 8:23 AM
To: Kernel Debugging Interest List
Subject: [windbg] No user mode debug prints seen on Win7, in a kernel mode
debug session.

Hi,

The machine I am talking about here is a Win7 system.

I have an App, which uses, OutputDebugStringW for printing debug traces.
This app will be started when the system starts(when the user logs in)

I would use DbgView in general. But I have situation where something’s going
wrong when it is started with the system restart.

I need to see the debug traces. so DbgView can not be used in this case.

I tried hooking to the test machine using WinDbg from a different machine.
But I see no user mode debug prints/trances in the WinDbg.

What to do about this? Are there any registry settings I need to manipulate
to see Debug prints?

Please suggest.

Regards,
Madhusudhana — WINDBG is sponsored by OSR 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


WINDBG is sponsored by OSR

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

This message has been scanned for viruses and
dangerous content by http:</http:> MailScanner, and is
believed to be clean.


WINDBG is sponsored by OSR

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

In a service, this will not work. Also many times the code you are debugging
is not aware of any windows that may or may not be in the app, and you would
have to generate a real hack to make this work.

On Thu, Jul 29, 2010 at 9:33 PM, M. M. O’Brien <
xxxxx@gmail.com> wrote:

Hmm. I have to take issue with the advice to not use the debugger for
trace statements. It?s where people expect to see them, and one day, you
very well might not be the one maintaining your code anymore.

Also, no matter what a license says, there are plenty of companies that
frown rather strongly on using code in this fashion. As in they fire you.

mm

Note that what you are saying is “it is where developers expect to see
them”, and my experience is that end users do not run programs under the
debugger. But my experience may be anomalous. Note that if you have a
better way to handle this, it makes it *easier* on future maintainers. They
don’t have to guess where the output is going, they *know*, because it is
part of the documentation.

I’ve also found that capturing the statements (e.g., using my Logging
ListBox) allows me to do better field support; I provide a GUI interface to
enable various logging options, and tell the end user to do File>Save Log
and email it to me; I’ve found bugs in third-party DLLs that way. If I had
used trace statements, either they would have been conditionally compiled
out of the release mode product or I would have had to have a long, complex
conversation with the customer on how to install a debug-port-capture
utility. The myth that there is a “console” to which you write “debug
output” (whether you launch a console window, as unregenerate Unix types
love to do, or use the debugger output window, is a minor point) leads you
down a garden path of cascading bad decisions. Seriously catastrophic
failures go to the event log, warning-level messages to the debug window
which the user can see, save, and email to you without special effort. Yes,
I use TRACE macros (which compile out in release mode) for fiddly-bits
debugging, but anything worthy of note about internal problems, API
failures, etc. goes to the event log or the logging window. A set of
convenient methods of the class make it easy to write formatted strings, and
handle error, warning, data trace, etc. easily and with a nice GUI
presentation. I can pass in a GetLastError code and get the FormatMessage
text in the window.

Twenty years of supporting software in the field has convinced me of the
value of this. The creation of WPP is an acknowledgement of the importance
of such mechanisms. Bottom line is that I would not use “debug console”
output for any purpose related to field support. Kernel failures get logged
to the event log. User-mode failures to my control in an application
window.

What “fashion” is being frowned on here? You jumped topic rather abruptly
with no explanation of what that last paragraph is referring to.

joe


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of M. M. O’Brien
Sent: Thursday, July 29, 2010 9:33 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] No user mode debug prints seen on Win7, in a kernel
mode debug session.

Hmm. I have to take issue with the advice to not use the debugger for trace
statements. It’s where people expect to see them, and one day, you very
well might not be the one maintaining your code anymore.

Also, no matter what a license says, there are plenty of companies that
frown rather strongly on using code in this fashion. As in they fire you.

mm

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
Sent: Thursday, July 29, 2010 7:10 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] No user mode debug prints seen on Win7, in a kernel
mode debug session.

First, if it is a console app, you should probably write to stderr instead
of using OutputDebugString. If it is a Windows app, you should be logging
things in a window, and forget you ever heard about OutputDebugString. You
can find a nice little class on my MVP Tips site, which I call the Logging
ListBox Control. I use it everywhere, and not once, in over 20 years of
Windows programming, have I ever called OutputDebugString for any purpose
whatsoever. Back in 1990, I decided this was a fundamentally losing
mechanism, and created my first logging listbox, which I did with an edit
control. Every beginner thinks the edit control is the right solution for
this problem, but it most decidedly is not; in fact, using an Edit control
is a poorer solution than OutputDebugString, which is already a very poor
solution. I learned, and well over 10 years ago, I released this control
for everyone to use. It is a very mature control, and the example shows how
to add “next error” and “previous error” buttons to your project and call
the interfaces. It can also save the log to a file, either at any time
(which assumes the app hasn’t crashed in some unrecoverable state) or
concurrent-with-logging, which means that the log file records events in
real-time (open, append, close, so it is always intact if your app
crashes)… It is a C++/MFC class, so if you are (shudder) programming in
raw Win32, you will have to adapt it to your environment. I have yet to
discover a reason to prefer raw Win32 API programming over MFC (I did it for
five years, discovered MFC, and never again wrote a raw Win32 API program).
You can learn MFC in two or three days, and it is worth the effort. (Oh
yes, it will take a couple years to master, but I get students building MFC
apps with 20 minutes of training when I teach the MFC course). MFC uses a
highly-stylized simple subset of C++, so you don’t need to learn C++ in all
its gloryXXXXXgory (I delivered my first C++ app in two weeks, never having
seen C++ in my life before that). If you want to program apps in native
code, learn MFC. The few days you spend doing this will pay back
tremendously in the years to come. Or learn WPF, or something like that.
But windowing apps built with the raw Win32 API are a waste of effort; you
can write then in a fraction of the time using MFC. And don’t try to tell
me that C programs in Win32 are “easier”; been there, done that, and they
most definitely are not!

My code is a free-use-for-whatever-purpose, and is NOT, repeat NOT, under
anything resembling the GNU license, so you are free to use it and you don’t
have to release your source.

It the event is a catastrophic failure, you probably want to write something
to the application log, anyway. You cannot expect your end users to know
how to set up to capture debug port output. So you should learn to write to
the event log from user space, which is a useful skill to know about. I can
even send an old (VS6) project I had that uses the mc compiler to create a
MESSAGETABLE resource; send me private email. But it is worth learning how
to use the even log. Note: this takes longer than learning how to use MFC.
And the payoff is high.

Essentially, if OutputDebugString did not exist, you would have to find a
reasonable way to report the error. So just pretend it doesn’t exist, and
proceed from there. No matter what solution you come up with, it will
certainly be better in every way from OutputDebugString (as long as you
don’t think an edit control is the solution!)

joe


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of M. M. O’Brien
Sent: Thursday, July 29, 2010 11:35 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] No user mode debug prints seen on Win7, in a kernel
mode debug session.

At what point in the restart cycle are you?

mm

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Madhusudan Narayan
Sent: Thursday, July 29, 2010 8:23 AM
To: Kernel Debugging Interest List
Subject: [windbg] No user mode debug prints seen on Win7, in a kernel mode
debug session.

Hi,

The machine I am talking about here is a Win7 system.

I have an App, which uses, OutputDebugStringW for printing debug traces.
This app will be started when the system starts(when the user logs in)

I would use DbgView in general. But I have situation where something’s going
wrong when it is started with the system restart.

I need to see the debug traces. so DbgView can not be used in this case.

I tried hooking to the test machine using WinDbg from a different machine.
But I see no user mode debug prints/trances in the WinDbg.

What to do about this? Are there any registry settings I need to manipulate
to see Debug prints?

Please suggest.

Regards,
Madhusudhana — WINDBG is sponsored by OSR 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


WINDBG is sponsored by OSR

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

This message has been scanned for viruses and
dangerous content by http:</http:> MailScanner, and is
believed to be clean.


WINDBG is sponsored by OSR

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


WINDBG is sponsored by OSR

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

This message has been scanned for viruses and
dangerous content by http:</http:> MailScanner, and is
believed to be clean.

When I see ‘OutputDebugString,’ I assume that we are talking about
developers; so does the op, apparently.

I have an App, which uses, OutputDebugStringW for printing debug traces.
This app will be started when the system starts(when the user logs in)
I> would use DbgView in general. But I have situation where something’s
going wrong when it is started with the system restart.
I tried hooking to the test machine using WinDbg from a different machine.
But I see no user mode debug prints/trances in the WinDbg.

As best as I can tell, this has nothing to do with ‘users;’ he’s trying to
debug his code. Also, in general, exactly what are users supposed to do
with this information? Even putting that aside, requiring that they read
the documentation to figure this out is what I would call nonstandard, which
is not easier. Easier for you, and perhaps easier for those who know how to
use it, but nobody else.

The event log is a sewer that nobody reads.

If you’re talking about logging, then I would absolutely agree that
OutputDebugString isn’t the feature to use, but neither is some random
window on the screen (which will also confuse those not expecting it). I
would go with a file in this case, but that’s neither here nor there, as
the op is pretty clearly (IMO) talking about debugging, not field support.

Regarding ‘fashion,’ you’re absolutely correct - I wasn’t clear. What I
meant was there are plenty of companies that disallow even referencing
anything ‘open source,’ because they are concerned about it getting into
their products. If you’re found with it, they frown on that. Big time.

Even in the absence of such a stated policy, in my opinion, including some
third party code that - nothing personal - you have no knowledge of because
somebody you don’t know says it’s perfectly fine to do so is a bad idea.

mm

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
Sent: Friday, July 30, 2010 12:35 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] No user mode debug prints seen on Win7, in a kernel
mode debug session.

Note that what you are saying is “it is where developers expect to see
them”, and my experience is that end users do not run programs under the
debugger. But my experience may be anomalous. Note that if you have a
better way to handle this, it makes it *easier* on future maintainers. They
don’t have to guess where the output is going, they *know*, because it is
part of the documentation.

I’ve also found that capturing the statements (e.g., using my Logging
ListBox) allows me to do better field support; I provide a GUI interface to
enable various logging options, and tell the end user to do File>Save Log
and email it to me; I’ve found bugs in third-party DLLs that way. If I had
used trace statements, either they would have been conditionally compiled
out of the release mode product or I would have had to have a long, complex
conversation with the customer on how to install a debug-port-capture
utility. The myth that there is a “console” to which you write “debug
output” (whether you launch a console window, as unregenerate Unix types
love to do, or use the debugger output window, is a minor point) leads you
down a garden path of cascading bad decisions. Seriously catastrophic
failures go to the event log, warning-level messages to the debug window
which the user can see, save, and email to you without special effort. Yes,
I use TRACE macros (which compile out in release mode) for fiddly-bits
debugging, but anything worthy of note about internal problems, API
failures, etc. goes to the event log or the logging window. A set of
convenient methods of the class make it easy to write formatted strings, and
handle error, warning, data trace, etc. easily and with a nice GUI
presentation. I can pass in a GetLastError code and get the FormatMessage
text in the window.

Twenty years of supporting software in the field has convinced me of the
value of this. The creation of WPP is an acknowledgement of the importance
of such mechanisms. Bottom line is that I would not use “debug console”
output for any purpose related to field support. Kernel failures get logged
to the event log. User-mode failures to my control in an application
window.

What “fashion” is being frowned on here? You jumped topic rather abruptly
with no explanation of what that last paragraph is referring to.

joe


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of M. M. O’Brien
Sent: Thursday, July 29, 2010 9:33 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] No user mode debug prints seen on Win7, in a kernel
mode debug session.

Hmm. I have to take issue with the advice to not use the debugger for trace
statements. It’s where people expect to see them, and one day, you very
well might not be the one maintaining your code anymore.

Also, no matter what a license says, there are plenty of companies that
frown rather strongly on using code in this fashion. As in they fire you.

mm

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
Sent: Thursday, July 29, 2010 7:10 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] No user mode debug prints seen on Win7, in a kernel
mode debug session.

First, if it is a console app, you should probably write to stderr instead
of using OutputDebugString. If it is a Windows app, you should be logging
things in a window, and forget you ever heard about OutputDebugString. You
can find a nice little class on my MVP Tips site, which I call the Logging
ListBox Control. I use it everywhere, and not once, in over 20 years of
Windows programming, have I ever called OutputDebugString for any purpose
whatsoever. Back in 1990, I decided this was a fundamentally losing
mechanism, and created my first logging listbox, which I did with an edit
control. Every beginner thinks the edit control is the right solution for
this problem, but it most decidedly is not; in fact, using an Edit control
is a poorer solution than OutputDebugString, which is already a very poor
solution. I learned, and well over 10 years ago, I released this control
for everyone to use. It is a very mature control, and the example shows how
to add “next error” and “previous error” buttons to your project and call
the interfaces. It can also save the log to a file, either at any time
(which assumes the app hasn’t crashed in some unrecoverable state) or
concurrent-with-logging, which means that the log file records events in
real-time (open, append, close, so it is always intact if your app
crashes)… It is a C++/MFC class, so if you are (shudder) programming in
raw Win32, you will have to adapt it to your environment. I have yet to
discover a reason to prefer raw Win32 API programming over MFC (I did it for
five years, discovered MFC, and never again wrote a raw Win32 API program).
You can learn MFC in two or three days, and it is worth the effort. (Oh
yes, it will take a couple years to master, but I get students building MFC
apps with 20 minutes of training when I teach the MFC course). MFC uses a
highly-stylized simple subset of C++, so you don’t need to learn C++ in all
its gloryXXXXXgory (I delivered my first C++ app in two weeks, never having
seen C++ in my life before that). If you want to program apps in native
code, learn MFC. The few days you spend doing this will pay back
tremendously in the years to come. Or learn WPF, or something like that.
But windowing apps built with the raw Win32 API are a waste of effort; you
can write then in a fraction of the time using MFC. And don’t try to tell
me that C programs in Win32 are “easier”; been there, done that, and they
most definitely are not!

My code is a free-use-for-whatever-purpose, and is NOT, repeat NOT, under
anything resembling the GNU license, so you are free to use it and you don’t
have to release your source.

It the event is a catastrophic failure, you probably want to write something
to the application log, anyway. You cannot expect your end users to know
how to set up to capture debug port output. So you should learn to write to
the event log from user space, which is a useful skill to know about. I can
even send an old (VS6) project I had that uses the mc compiler to create a
MESSAGETABLE resource; send me private email. But it is worth learning how
to use the even log. Note: this takes longer than learning how to use MFC.
And the payoff is high.

Essentially, if OutputDebugString did not exist, you would have to find a
reasonable way to report the error. So just pretend it doesn’t exist, and
proceed from there. No matter what solution you come up with, it will
certainly be better in every way from OutputDebugString (as long as you
don’t think an edit control is the solution!)

joe


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of M. M. O’Brien
Sent: Thursday, July 29, 2010 11:35 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] No user mode debug prints seen on Win7, in a kernel
mode debug session.

At what point in the restart cycle are you?

mm

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Madhusudan Narayan
Sent: Thursday, July 29, 2010 8:23 AM
To: Kernel Debugging Interest List
Subject: [windbg] No user mode debug prints seen on Win7, in a kernel mode
debug session.

Hi,

The machine I am talking about here is a Win7 system.

I have an App, which uses, OutputDebugStringW for printing debug traces.
This app will be started when the system starts(when the user logs in)

I would use DbgView in general. But I have situation where something’s going
wrong when it is started with the system restart.

I need to see the debug traces. so DbgView can not be used in this case.

I tried hooking to the test machine using WinDbg from a different machine.
But I see no user mode debug prints/trances in the WinDbg.

What to do about this? Are there any registry settings I need to manipulate
to see Debug prints?

Please suggest.

Regards,
Madhusudhana — WINDBG is sponsored by OSR 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


WINDBG is sponsored by OSR

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

This message has been scanned for viruses and
dangerous content by http:</http:> MailScanner, and is
believed to be clean.


WINDBG is sponsored by OSR

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


WINDBG is sponsored by OSR

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

This message has been scanned for viruses and
dangerous content by http:</http:> MailScanner, and is
believed to be clean.


WINDBG is sponsored by OSR

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