Using Debug View with programs that run before the Windows XP login prompt
cappy2112
I've written a Native application - and as such it runs before the XP
login prompt.
I've added some calls to DbgPrint- and would like to see if there's a
way to monitor them from a remote machine, without having to install
windbg on both machines.
So I've found DbgView from SysInternals.com/ Microsoft.com, and it has
client/server capabilities.
http://www.microsoft.com/technet/sysinternals/Miscellaneous/DebugView.mspx
Is it possible to use it to monitor my DbgPrint calls remotely?
I've read the help file and understand how to invoke it to connect to
a remote machine- that has already been logged into.
However, DbgView won't run at the same point when a Native app runs,
because it is not a Native app itself.
But it seems as though DbgView should be able to "catch" the output
from programs that are calling DbgPrint.
Does anyone have any suggestions as to how to monitor the output from
DbgPrint- from a Native app?
thanks
Don Burn
"cappy2112" <capp...@gmail.com> wrote in message
>
> Does anyone have any suggestions as to how to monitor the output from
> DbgPrint- from a Native app?
>
WinDBG with a kernel serial connection will do it.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
cappy2112
Yes- I know it will.
As I had mentioned in the original message- I'm trying to avoid
installing WinDbg.
Customers tend to not like installing sw to debug on their machines,
and in my use of WinDbg- it is not always reliable, often hangs the
machine- or causes enough changes that problems don't reproduce
themselves.
On Sep 16, 1:39 pm, "Don Burn" <b...@stopspam.windrvr.com> wrote:
> "cappy2112" <cappy2...@gmail.com> wrote in message
Don Burn
>
> Yes- I know it will.
> As I had mentioned in the original message- I'm trying to avoid
> installing WinDbg.
> Customers tend to not like installing sw to debug on their machines,
> and in my use of WinDbg- it is not always reliable, often hangs the
> machine- or causes enough changes that problems don't reproduce
> themselves.
>
1. Must be installed on the machine being debugged
2. Patches the kernel when it runs
While I have seen problems with WinDBG nowadays they are all on the host
machine (unlike DebugView where I have lost the OS once due to accidently
running an old version on a new OS). I can't believe most customers will
have problems with you adding a boot.ini option if they will allow you to
run DebugView.
WinDBG is the only way to get debug messages without installing 3rd party
software on the computer in question.
cappy2112
> 1. Must be installed on the machine being debugged
> 2. Patches the kernel when it runs
How can it patch the kernel from user space?
Wen I first read about DebugView- I was envisioning it would only run
on the remote machine, and I hoped that DebugPrint() had enough
functionality to get the debug strings over to the remote machine
running it.
> have problems with you adding a boot.ini option if they will allow you to
> run DebugView.
It's not debug view I'm concerned about. I'd much rather use it than
go through the hoops to install Windebug.
Windebug is a lot more complicated and needs much more files installed
on the target machine. Trying to get the right set of symbols
installed on the target is a pain.
No matter which symbols I've installed, Windebug always complains
about something- and many times wont even stop so I can set
breakpoints.
DebugView is one little exe file- and much easier to use. Like I
said- I was hoping I could only run it from the remote. The docs for
it sure give that impression. Something to the fact of "it will
install itself on the target machine"- or something along those lines.
So at this point, I need to install Windebug
thanks
Don Burn
>> Well Debug View is a heck of a lot more instrusive than WinDBG since it:
>> 1. Must be installed on the machine being debugged
>> 2. Patches the kernel when it runs
>
> How can it patch the kernel from user space?
>
> Wen I first read about DebugView- I was envisioning it would only run
> on the remote machine, and I hoped that DebugPrint() had enough
> functionality to get the debug strings over to the remote machine
> running it.
DebugView installs a driver that is in the resource section of the binary.
This is why you need administrator priviledge to run DebugView.
>> have problems with you adding a boot.ini option if they will allow you
>> to
>> run DebugView.
>
> It's not debug view I'm concerned about. I'd much rather use it than
> go through the hoops to install Windebug.
> Windebug is a lot more complicated and needs much more files installed
> on the target machine. Trying to get the right set of symbols
> installed on the target is a pain.
THERE ARE NO FILES THAT HAVE TO BE INSTALLED ON THE TARGET MACHINE FOR
WINDGB. This has been true for 13 years I have used the product. What are
you talking about? Getting the correct symbols are only needed if you need
to debug, you have already ruled this out since you only want DbgPrint
output which works even if none of the symbols are correct.
> No matter which symbols I've installed, Windebug always complains
> about something- and many times wont even stop so I can set
> breakpoints.
Use the symbol server, this will eliminate the WinDbg symbol problems
except for your files.
> DebugView is one little exe file- and much easier to use. Like I
> said- I was hoping I could only run it from the remote. The docs for
> it sure give that impression. Something to the fact of "it will
> install itself on the target machine"- or something along those lines.
Actually, it is a lot more than one little exe, but the rest is hidden.
No, you cannot just run it remote.
Alan Adams
> Does anyone have any suggestions as to how to monitor the output from
> DbgPrint- from a Native app?
Since you didn't already mention it by name, have you confirmed that
DebugView's "Log boot" option does not catch this? (Nothing to do
with "client server capabilities"; just a matter of whether DebugView
installs its driver to be persistent over the next boot.)
"Log boot" is an option you select from the DebugView "Capture" menu
which sets up a one-time option for its driver to run during the next
boot. During startup the output is queued until you finally get
logged in and/or run the DebugView UI again.
The DebugView authors confirmed a while back that the "Log boot"
option will not capture user-mode debug output via the "Log boot"
method. (e.g. You can't get debug output off LSASS.EXE or
WINLOGON.EXE this way; just output from kernel-mode drivers.)
But I can't say I've specifically tried it with a native mode
application.
Alan Adams
cappy2112
> DebugView's "Log boot" option does not catch this?
I had found out about this just today, tried it, but nothing was
captured.
There is very little in the help file about it, so it doesn't appear
there are many factors involved to make it work, other than lcikcing
on the Log Boot option.
> The DebugView authors confirmed a while back that the "Log boot"
> option will not capture user-mode debug output via the "Log boot"
> method. (e.g. You can't get debug output off LSASS.EXE or
> WINLOGON.EXE this way; just output from kernel-mode drivers.)
Being that this is the first time I've worked with a native app, I
would expect that it does not qualify as a user mode app.
I think the help file mentions that the intention is to capture output
from the kernel level, however, it did not capture anything form my
native app.
cappy2112
> THERE ARE NO FILES THAT HAVE TO BE INSTALLED ON THE TARGET MACHINE FOR
> WINDGB. This has been true for 13 years I have used the product. What are
> you talking about? Getting the correct symbols are only needed if you need
> to debug, you have already ruled this out since you only want DbgPrint
> output which works even if none of the symbols are correct.
My first experience with windbg was to debug this native app that I am
working on.
Getting windebug working was quite problematic, and I had spent a lot
of time reading the documentation.I typically develop in user mode
only. Issues invovled with working at this level are quite confusing,
but I've actually made the native app work-considering there is almost
no documentation other than an outdated book from early Win2k days.
I am not aware that nothing needs to be installed on the target to use
windbg.
You are correct that the symbols aren't need to catch dbgprint output.
I had just lumped my experiences from windg into this thread. A bad
idea on my part.
> Actually, it is a lot more than one little exe, but the rest is hidden.
There is mention of a dbgview.sys file- either in the help file, or on
sysinternals, but it is not in the zip file which is available for
download.
perhaps this is the driver code that is now embedded in the executable
Well, it looks like I need to see how to get windebug working again.
Thanks for your input.
.
Avi Cohen Stuart
Why don't you open a file yourself and write these messages to that file?
Make it selectable by a resource or something to enable or disable it. Or
dependent on another file whether it exists or not.
Avi.
"cappy2112" <capp...@gmail.com> wrote in message
news:1189974049....@g4g2000hsf.googlegroups.com...
cappy2112
Very Good question-
During the time that a Native app runs- the Win32 subsystem isn't
functional.
That gives me the impression that the filesystem isn't available for
normal I/O, but I don't know for sure.
Also- I feel it may be risky writing to a file- especially if the app
is misbehaving.
I'd hate to write to a customer's disk and trash something important.
Additionally, I wasn't able to find the API's that can be called from
a native app, in order to write a file, but
even if I had an example of how to do it, I'd still rather avoid it.
A lot of my concerns are probably ill-founded because I haven't worked
at this level before, and there is only 1 very out of date API
reference available.
If you're aware of some examples of native applications, please let me
know
On Sep 17, 7:27 am, "Avi Cohen Stuart"
Avi Cohen Stuart
Look here for example:
http://www.osronline.com/article.cfm?id=91
but sign up before.
Regards and good luck,
Avi.
"cappy2112" <capp...@gmail.com> wrote in message
news:1190152762.7...@v23g2000prn.googlegroups.com...
cappy2112
<aviXcohenXstuart@ssaglobalXcom> wrote:
> Hi,
>
> Look here for example:
>
> http://www.osronline.com/article.cfm?id=91
>
> but sign up before.
>
> Regards and good luck,
>
> Avi.
>
Awesome. I wish I would have had this article a few months ago.
Thank you very much !!!