Really? I can’t believe it. This is the next level of recklessness and/or stupidity after leaving unconditional debug prints in released code.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Chesong Lee[SMTP:xxxxx@enterprisent.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, December 19, 2007 1:27 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] RE:How to use windbg to debug an application on another target computer?At least, please do not leave such *unconditional* DebugBreak() in
released device drivers or any applications. Even though the original
developers may want to break in for every time their driver or service
starts, we do not want to be interrupted by other’s DebugBreak() when
we debug ours. I have seen such behaviors in some device drivers and
user-mode applications as well.Chesong Lee
On Dec 18, 2007 3:46 PM, wrote:
> > I remember reading this, and I thought it was for the drivers or kernel
> > modes. Actually I’ve been doing this for services for quite some time, and
> > did not hit so much of a trouble.
> >
> > If you remember anthing special please mention here ( before we spiral
> > into another undocumented stuff
> >
> > And the service have been using is pretty darn large ( 3 to 4 hundred
> > thousand lines of frame work it is large telecom framework for voip type
> > stuff
> >
> > -pro
> >
> >
> > > DO NOT DO THIS. Read NT Insider article about using this technique and
> > > the
> > > interrupt bit in the flags register. Been bit by it.
> > >
> > > “Prokash Sinha” wrote in message news:xxxxx@ntdev…
> > >> You can try the following two options ( whatever works for you ) -
> > >>
> > >> Since you said you are driver developer, and comfortable using kernel
> > >> debugger.
> > >>
> > >> 1) If you have the source of your application, at the start of your app
> > >> ( some main, Winmain, _tmain etc ) use a code something like this -
> > >>
> > >> __try {
> > >> DebugBreak(); // look at win32 api for Breakpointing
> > >> }
> > >>__except ( 1 )
> > >> {
> > >> //put some print stmt or even null stmt ( ; )
> > >> }
> > >>
> > >> Now build and run aftere you booted the target with kernel debugging
> > >> enabled. It would break in and you will have control in the windbg of
> > >> host machine. Now you can debug the app this way, but remember that you
> > >> are now using the windbg kernelmode debugging.
> > >>
> > >> 2) Or you can just bring up the windbg on the target machine, and
> > >> execute
> > >> or attach to the app from your debugger, it will break in to runtime
> > >> routines before your main gets called. At that point
> > >> issue the following command from your target machine’s debugger command
> > >> line -
> > >>
> > >> .server tcp:port=2000, icfenable
> > >>
> > >> Watch the string spews out as a response to your command
> > >>
> > >> Now on the host machine, bring up your windbg client, there is an option
> > >> for remote debugging, click that to get a dlg box prompt. Use the
> > >> machine
> > >> name or ip that prompted in your previous command as below
> > >>
> > >> tcp:port=2000,
> > >>
> > >> If you have XP firewall then you may have to go to control panel …
> > >> security configuration … firewall setting to allow windbg as an
> > >> exception. Most of the time disabling the firewall temporarily works
> > >> fine.
> > >>
> > >> I use option (1) whenever I do debug app or services …
> > >>
> > >> -pro
> > >> ----- Original Message -----
> > >> From:
> > >> To: “Windows System Software Devs Interest List”
> > >> Sent: Tuesday, December 18, 2007 2:25 AM>
> > >> Subject: RE:[ntdev] How to use windbg to debug an application on another
> > >> target computer?
> > >>
> > >>
> >
> > >>>I installed windbg on my target machine. And then I run the below
> > >>> command:
> > >>>
> > >>> dbgsrv.exe -t com:port=1,baud=115200
> > >>>
> > >>> but unluckily, it reports “StartProcessServer Error 0x80070057” .
> > >>> Oh!!!
> > >>>
> > >>> —
> > >>> NTDEV 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
> > >>
> > >>
> > >
> > >
> > >
> > > —
> > > NTDEV 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
> > >
> >
> >
> >
> > —
> > NTDEV 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
> >
>
> —
> NTDEV 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
>
