Hi,
I only know how to debug drivers with windbg. Could anyone please tell me how to debug applications on another target computer with windbg? I mean, my windbg is installed on my host computer.
Thank you!
See “Remote Debugging Through the Debugger” in the windbg help. I generally
use named pipes as the communication mechanism.
On Dec 15, 2007 5:12 AM, wrote:
> Hi,
>
> I only know how to debug drivers with windbg. Could anyone please tell me
> how to debug applications on another target computer with windbg? I mean, my
> windbg is installed on my host computer.
>
> Thank you!
>
> —
> 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
>
–
Mark Roddy
Hi,
Do you mean that I really can use windbg to debug applications on a target machine?
And do you mean that I can debug applications just by following the same steps as debugging drivers?
And in fact, could you tell me the frequently used windbg commands while debugging applications?
Thank you!
No the steps for debugging applications are somewhat different than the
steps for debugging the kernel. You asked about remote debugging
applications, and one way I would do that is to set up the target system
with a windbg named pipe server and debug from the remote system using a
local windbg client. This is all documented in the windbg help. Actually, on
reflection, if you can termserve into the test system, just do remote
debugging that way.
The visual studio remote debugging capabilities are somewhat more
sophisticated than windbgs, so I tend to us VS for application debugging and
windbg strictly for kernel debugging. On the other hand the security mess in
the VS remote debugger is such a PITA that I have on occasion chucked it for
the simplicity of windbg.
Just read the help files.
On Dec 16, 2007 8:32 PM, wrote:
> Hi,
> Do you mean that I really can use windbg to debug applications on a target
> machine?
> And do you mean that I can debug applications just by following the same
> steps as debugging drivers?
> And in fact, could you tell me the frequently used windbg commands while
> debugging applications?
> Thank you!
>
> —
> 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
>
–
Mark Roddy
Just to give another option -
You can debug applilcation remotely using windbg. In this case, your remote machine will have a client instance running ( client instance means you have the windbg windows user interface is running on the remote). And in this case you will have to run the application under this windbg instance or you will have to attach to a process. Almost always it is your manual intervention in the target machine ( unless you set windbg as your default debugger, and have imbedded interrupt that would agitate the systems to invoke the debugger ) to get the app working under windbg debugger. Once you done that, you can redirect that using for example ( .server tcp:port 2000 icfenable ) or something like this. Then you can openup another windbg from just about any machine and use the (.remore tcp:port 2000 ).
But the above procedure is not what we call a target and dev machine pairing. This pairing implies that the debugger is working in kernel debugging mode. From your post it seems like you don’t want the above procedure, but just in case whatever it’s worth !!!
-pro
----- Original Message -----
From: Mark Roddy
To: Windows System Software Devs Interest List
Sent: Sunday, December 16, 2007 7:11 PM
Subject: Re: [ntdev] How to use windbg to debug an application on another target computer?
No the steps for debugging applications are somewhat different than the steps for debugging the kernel. You asked about remote debugging applications, and one way I would do that is to set up the target system with a windbg named pipe server and debug from the remote system using a local windbg client. This is all documented in the windbg help. Actually, on reflection, if you can termserve into the test system, just do remote debugging that way.
The visual studio remote debugging capabilities are somewhat more sophisticated than windbgs, so I tend to us VS for application debugging and windbg strictly for kernel debugging. On the other hand the security mess in the VS remote debugger is such a PITA that I have on occasion chucked it for the simplicity of windbg.
Just read the help files.
On Dec 16, 2007 8:32 PM, wrote:
Hi,
Do you mean that I really can use windbg to debug applications on a target machine?
And do you mean that I can debug applications just by following the same steps as debugging drivers?
And in fact, could you tell me the frequently used windbg commands while debugging applications?
Thank you!
—
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
–
Mark Roddy — 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
Hi,
Your ways are valuable for me. Really I want to know whether I can use “com” or “1394” to debug applications which run on another target machine. If the answer is “no”, then I will follow your ways, I mean, I will use “remote debugging”.
Thank you!
Well then, let me take it from here -
Using com or 1394 is usually for kernel debugging. What is kernel debugging
then ?. Basically you are able to intercept kernel mode components ( such as
drivers and other kernel mode modules, and these are built with DDKs), when
the debugger runs in kernel mode. And in this particular case where you have
the windbg client window is nothing but a visual representation of what the
debugger is doing on the target machine. If you are not interested in
debugging kernel mode software then you could think about this route
later…
Now for application debugging, you really don’t need two or machines (
unless you want to debug an app running on a machine that is remotely
located from your place). Assuming you know how to debug an app running
locally, but you want to debug an app running on a remote machine, there are
several options -
Option one that Mark said is to use terminal server. That is basically you
rdp into the target machine and see everything on that machine (as if it is
your own machine ), and obviously you can debug app running on that machine.
Alternatively, you can use the .server and .remote command ( dot commands )
ebug console to another windbg client ( as I said in earlier email). Now
for the transport ( i.e what are the different transport you can use )
please look at the windbg help - it is quite extensive help. It may be
possible to use named pipe over 1394. But I know tcp/ip works great…
-pro
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Sunday, December 16, 2007 9:22 PM
Subject: RE:[ntdev] How to use windbg to debug an application on another
target computer?
> Hi,
>
> Your ways are valuable for me. Really I want to know whether I can use
> “com” or “1394” to debug applications which run on another target machine.
> If the answer is “no”, then I will follow your ways, I mean, I will use
> “remote debugging”.
> Thank you!
>
> —
> 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
Hi,
Really I am a driver developer. But this time I have to use two machines to debug just applications. You know, sometimes the GUI debugger will affect the application greatly. So I have no choices.
I have checked windbg’s help documents just now and find the below comments:
.server com:port=COMPort,baud=BaudRate,channel=COMChannel[,hidden][,password=Password]
So it seems that I can use a “com” port to create a debugging server. And I have no “1394” port on my computer, so I will try “com” port first.
And as you mentioned, I will try “TCP/IP” connection if “com” port doesn’t effect.
I will tell my results after my tests over. Thank you!
>You can debug applilcation remotely using windbg. In this case, your remote
machine will have a client instance running ( client instance means you have
the
windbg windows user interface is running on the remote).
I think that it is a tiny REMOTE.EXE applet running on the remote and not the
WinDbg UI.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
You can run a server either using remote.exe or the windbg ui.
On Dec 17, 2007 7:41 AM, Maxim S. Shatskih wrote:
> >You can debug applilcation remotely using windbg. In this case, your
> remote
> >machine will have a client instance running ( client instance means you
> have
> the
> >windbg windows user interface is running on the remote).
>
> I think that it is a tiny REMOTE.EXE applet running on the remote and not
> the
> WinDbg UI.
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> 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
>
–
Mark Roddy
Do you mean I should install “windbg” on the “target” machine? What is your meaning of “remote” and “client”? Does “remote” mean “target”, and “client” mean “host” ?
Should I install windbg on both machines? Should I use “cdb.exe” or “remote.exe” to run the command “.server” ? Should I use “windbg.exe” to run the command “.remote”?
I am confused. Please tell me the steps.
Thank you!
Let’s assume you want to debug the application (myapp.exe) running in
the host (foo).
-
Copy dbgeng.dll, dbghelp.dll and dbgsrv.exe in
%ProgramFiles%\Debugging Tools for Windows from your machine to “foo”.
You can install the entire package of “Debugging Tools for Windows” to
foo as well if you want. -
From foo, execute dbgsrv.exe (e.g. in tcp port 1234)
C:\> dbgsrv.exe -t tcp:port=1234
- From your computer, execute windbg
C:\Program Files\Debugging Tools for Windows> windbg -premote
tcp:port=1234,host=foo c:\myapp.exe
C:\Program Files\Debugging Tools for Windows> windbg -premote
tcp:port=1234,host=foo -pn myapp.exe
Hope this helps.
On Dec 17, 2007 5:58 PM, wrote:
> Do you mean I should install “windbg” on the “target” machine? What is your meaning of “remote” and “client”? Does “remote” mean “target”, and “client” mean “host” ?
> Should I install windbg on both machines? Should I use “cdb.exe” or “remote.exe” to run the command “.server” ? Should I use “windbg.exe” to run the command “.remote”?
> I am confused. Please tell me the steps.
> Thank you!
>
>
> —
> 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
>
Thank you. Let me try. I will come back while having results.
This is the idea, but there’s a small error, I believe:
- This:
windbg -premote tcp:port=1234,host=foo c:\myapp.exe
should be
windbg -premote tcp:port=1234,server=foo c:\myapp.exe
and similarly for the -pn variant.
Also, this machine is not the host, in WinDbg terminology; it’s the
server. I don’t mean to nitpick, but the WinDbg nomenclature in this
area, combined with the less than clear documentation on what appears to
be 100 ways to remote debug, is a little overwhelming for a beginner,
and even experienced people have to keep referring to the documentation
to figure it out sometimes, which is very difficult to do if it doesn’t
match the documentation’s conventions. In this particular case,
although host and server as frequently used interchangably in other
contexts without confusion, using host this way makes it very easy for
one who is familiar with setting up a kernel debugging session to think
that one is talking about the ‘smart client’ - the machine which the
user sits at to operate the debugger, is it would be in a kd connection.
Good luck,
mm
Chesong Lee wrote:
Let’s assume you want to debug the application (myapp.exe) running in
the host (foo).
Copy dbgeng.dll, dbghelp.dll and dbgsrv.exe in
%ProgramFiles%\Debugging Tools for Windows from your machine to “foo”.
You can install the entire package of “Debugging Tools for Windows” to
foo as well if you want.From foo, execute dbgsrv.exe (e.g. in tcp port 1234)
C:\> dbgsrv.exe -t tcp:port=1234
- From your computer, execute windbg
>
> C:\Program Files\Debugging Tools for Windows> windbg -premote
> tcp:port=1234,host=foo c:\myapp.exe
>
>
>
> C:\Program Files\Debugging Tools for Windows> windbg -premote
> tcp:port=1234,host=foo -pn myapp.exe
>
> Hope this helps.
>
> On Dec 17, 2007 5:58 PM, wrote:
>> Do you mean I should install “windbg” on the “target” machine? What is your meaning of “remote” and “client”? Does “remote” mean “target”, and “client” mean “host” ?
>> Should I install windbg on both machines? Should I use “cdb.exe” or “remote.exe” to run the command “.server” ? Should I use “windbg.exe” to run the command “.remote”?
>> I am confused. Please tell me the steps.
>> Thank you!
>>
>>
>> —
>> 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
>>
>
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!!!
You can try the following two options ( whatever works for you ) -
Since you said you are driver developer, and comfortable using kernel
debugger.
- 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.
- 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
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
>
>
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
>
Yes, specifically for kernel mode. Ntdev is almost exclusively kernel mode
drivers, though sometimes another subject appears. I don’t know about
applications and if it could have a problem. Read the article and see if
the undesirable side effects are proprogated in user mode or not. I would
test the IF in the except handler and see if interrupts are enabled. If
not, then you have the same problem but not as much of an impact as in
kernel mode. Interrupts will be processed by the kernel mode drivers but
any callbacks, APCs, or other activities might not get forwarded to you
while interrupts are disabled. I just don’t do enough applications to know
or even much care. I do apps but only for testing or personal use if I have
a major need no one else has fulfilled.
wrote in message news:xxxxx@ntdev…
>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
>>
>
>
>
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
>