Oleksiy,
If you are repeatedly running a specific process, consider using the “Image
File Execution Options”, with “cdb -server …”. For example, if your
executable is foo.exe, open RegEdit, go to “HKLM\Software\Microsoft\Windows
NT\CurrentVersion\Image File Execution Options”, and create a key named
“foo.exe” (without the quotes). Then, under that key, create a value named
“Debugger” with type REG_SZ, and set it to “c:\dbg\cdb -remote
tcp:port=4000”. (Replace d:\dbg with your own path, of course.)
The Win32 CreateProcess call checks the “Image File Execution Options” key
every time it runs, and looks for the Debugger value. If present, it
prepends the value of the Debugger key to the command line string provided
to CreateProcess. So, whenever foo.exe runs, it will run under a debugger,
and the “-remote tcp:port=4000” argument to the debugger will cause the
debugger to immediately create a server port and allow remote debuggers to
attach.
Then you can attach from another machine with “windbg -remote
tcp:port=4000,server=xxx” (where xxx is your other machine’s name or IP
address).
Note: By default, CDB will start the process in a “halted” state, and you’ll
have to hit F5 / type “g” to get the process to run. But that sounds like
what you want anyway. You can specify -g in the Debugger value to cause the
process to start normally, and -G to ignore the process termination
breakpoint. This is particularly useful for debugging Win32 services, which
run in a different session and window station (by default).
The advantage of this approach is that you never need to deal with
enumerating processes / PIDs and choosing one – the debugger always uses
the same TCP/IP port. This simplifies the workflow of debugging. However,
that’s also a disadvantage, if you need to start multiple instances of the
same process. This technique is also problematic if you are debugging DLL
code AND when the EXE that hosts your code is a common process, such as
svchost.exe.
– arlie
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Oleksiy Shatylo
Sent: Thursday, February 16, 2006 2:39 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Defects in user mode remote debugging scenario with
initially suspended application
Hello Drew,
Take off my hat. I just did not think that solution can be so simple and
executable will start from and on remote machine.
Thank you a lot for tip. Usually I run process manually on remote machine
where DbgSrv.exe was running and then I used “Attach” window to debug the
process. Of course, in this way I was unable to debug process
initialization.
Because of this I used way with suspended process 
Best regards,
Oleksiy Shatylo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Thursday, February 16, 2006 6:45 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Defects in user mode remote debugging scenario
with initially suspended application
I think perhaps there’s a misunderstanding about the nature of dbgsrv.
As I mentioned it isn’t a one-shot application.
You generally do not specify your application name when starting
dbgsrv, the -c and -cs options are for special-purpose usage with
Image File Execution Options.
Instead, if you’re just interested in using dbgsrv in its normal role
as a process server you simply start dbgsrv without any specific
process specification. You provide session information with the
debugger to start as many sessions as you like. It works very much
like Visual Studio remote debugging.
Your problems are not related to remote debugging, they have to do
with suspended processes. You don’t need to use suspended processes,
though, so you can simplify your debugging by not using -cs. You then
don’t need to use -pr nor -pb.
dbgsrv -t tcp:port=1234
then
windbg -premote tcp:port=1234,server=xxx regedit.exe
Note that I can have dbgsrv create the regedit debuggee for me on
demand instead of having to specify it when starting dbgsrv, thus
making things easier all around.
This is the expected usage model for dbgsrv remote debugging, which is
why we haven’t done GUI equivalents of -pr and -pb
– there’s no real need – nor do we attempt to do special detection
of suspended processes, nor does dbgsrv need special one-shot usage
options.
From: xxxxx@lists.osr.com on behalf of Oleksiy Shatylo
Sent: Thu 2/16/2006 3:17 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Defects in user mode remote debugging scenario
with initially suspended application
Hello Drew,
> 2. dbgsrv is a server and not a one-shot tool so it is
intended to run
> until explicitly shut down. You can request a shutdown
from a client
> with .endpsrv.
Well, it is not very important but could WinDbg team attempt to
implement additional command line option that implicitly will do
exactly that .endpsrv is doing after application is terminated? This
option will be applied only as additional (but not mandatory) option
to -c command.
I meant something like -c[s][e] AppCmdLine where e is calling .endpsrv
when specified process terminated. Of course, in such case DbgSrv
should do equivalent of .endpsrv only in case if no other process
being debugged using DbgSrv instance with this option turned on. Such
limitation/behavior can be explained in documentation or other
processes can be grayed or not selectable in “Attach” window.
> 3a. Searching for a process name and getting per-PID
information are
> fundamentally different code paths. The first scans all
processes and
> uses a whole-system enumeration to get its information.
The per-PID
> info is done for a single process and so uses process-specific
> queries, thus it has slightly different access requirements and
> failure points.
> Even though windbg’s attach dialog ends up getting info for
all PIDs
> the individual process information is recovered by per-PID
queries as
> this allows more flexibility over what information is
gathered per-PID
> and lets the dialog defer getting detailed information
until a leaf is
> expanded. You are correct that windbg could actually recover the
> process names by whole-system enumeration at any time but
that would
> be impractical for per-PID queries. We will put an item on our
> future-consideration list to have windbg use a hybrid approach when
> getting the full process list for the attach dialog.
>
> 3b. Command line attach options only apply to command line attach
> debugging, so -pr and -pb only apply to an eventual -p. If you go
> through the Attach Process GUI you are defining a new
attach attempt.
> The failures you are seeing are expected when -pr and -pb
aren’t used.
> We will put GUI equivalents of -pb and -pr on our
future-consideration
> list. For now just specify your attach attempt on the command line.
Thank you a lot for acceptance of these bug reports.
I hope that it will help to make WinDbg even better than it is now.
> 3c. The process failure is expected when -pb and -pr aren’t
used. A
> process created suspended is only partly initialized since the
> user-mode finalization of the process create hasn’t run
yet. If you
> attach a debugger to a process in this state and let an
initial break
> run that break code will run against the
partially-initialized state
> and thus will cause problems.
> This is OS behavior and the debugger can’t get around it.
But if WinDbg team knows about such problem then could WinDbg team
implement some workaround/fix that will query first process server and
if process server reports that process is suspended then WinDbg will
disable initial break implicitly or will display message box with
appropriate question (something like “Process to which you trying to
attach is suspended. Should WinDbg turn off initial break?”). Sure, it
can be helpful behavior of WinDbg for newbie that is trying to switch
from Visual Studio remote debugging to WinDbg/DbgSrv.
Best regards,
Oleksiy Shatylo
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
> Sent: Wednesday, February 15, 2006 9:19 PM
> To: Kernel Debugging Interest List
> Subject: RE: [windbg] Defects in user mode remote debugging
scenario
> with initially suspended application
>
> 2. dbgsrv is a server and not a one-shot tool so it is
intended to run
> until explicitly shut down. You can request a shutdown
from a client
> with .endpsrv.
>
> 3a. Searching for a process name and getting per-PID
information are
> fundamentally different code paths. The first scans all
processes and
> uses a whole-system enumeration to get its information.
The per-PID
> info is done for a single process and so uses process-specific
> queries, thus it has slightly different access requirements and
> failure points.
> Even though windbg’s attach dialog ends up getting info for
all PIDs
> the individual process information is recovered by per-PID
queries as
> this allows more flexibility over what information is
gathered per-PID
> and lets the dialog defer getting detailed information
until a leaf is
> expanded. You are correct that windbg could actually recover the
> process names by whole-system enumeration at any time but
that would
> be impractical for per-PID queries. We will put an item on our
> future-consideration list to have windbg use a hybrid approach when
> getting the full process list for the attach dialog.
>
> 3b. Command line attach options only apply to command line attach
> debugging, so -pr and -pb only apply to an eventual -p. If you go
> through the Attach Process GUI you are defining a new
attach attempt.
> The failures you are seeing are expected when -pr and -pb
aren’t used.
> We will put GUI equivalents of -pb and -pr on our
future-consideration
> list. For now just specify your attach attempt on the command line.
>
> 3c. The process failure is expected when -pb and -pr aren’t
used. A
> process created suspended is only partly initialized since the
> user-mode finalization of the process create hasn’t run
yet. If you
> attach a debugger to a process in this state and let an
initial break
> run that break code will run against the
partially-initialized state
> and thus will cause problems.
> This is OS behavior and the debugger can’t get around it.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Oleksiy
> Shatylo
> Sent: Wednesday, February 15, 2006 5:08 AM
> To: Kernel Debugging Interest List
> Subject: [windbg] Defects in user mode remote debugging
scenario with
> initially suspended application
>
> Hello All,
>
> I am just trying user mode remote debugging scenario with initially
> suspended application. In defects demonstration I am using
RegEdit.exe
> that should be present on any Windows XP system.
>
> 1. To start debugging server I used following command on target
> computer accordingly to documentation from WinDbg:
> dbgsrv.exe -t tcp:port=2:7 -cs %SystemRoot%\regedit.exe
>
>
> 2. I used following batch file to start WinDbg:
>
> set
> _NT_SYMBOL_PATH=srv*D:\MSWebSymbols*http://msdl.microsoft.com/
> download/s
> ymbo
> ls
> windbg -premote tcp:server=192.168.22.40,port=2:7 -pr -pb -WX -pn
> regedit.exe
>
> Debugging session started fine but with one exception - the
debugging
> server is not terminated after RegEdit.exe was terminated
on target.
> Is it expected behavior from DbgSrv.exe in this case? It
seems to me
> that it is a bug.
>
> 3. I terminated remaining DbgSrv.exe process that was present after
> step
> 2 and repeated step 1. Afterwards I modified a bit batch
file to start
> WinDbg (I just removed -pn regedit.exe).
>
> set
> _NT_SYMBOL_PATH=srv*D:\MSWebSymbols*http://msdl.microsoft.com/
> download/s
> ymbo
> ls
> windbg -premote tcp:server=192.168.22.40,port=2:7 -pr -pb -WX
>
> I attached to remote debugging server successfully. Then I chose
> “Attach to a Process” but instead of process name I saw “Error
> 0x8007012B” in shown window although the process PID was shown
> correctly.
> 0:002> !error 0x8007012B
> Error code: (HRESULT) 0x8007012b (2147942699) - Only part of a
> ReadProcessMemory or WriteProcessMemory request was completed.
>
> Definitively if previous command from step 2 detected process name
> correctly then process name should be displayed correctly in shown
> window too. In my eyes it is bug (cosmetic).
>
> I chose RegEdit.exe process and clicked OK button. In WinDbg I
> received following output:
> Microsoft (R) Windows Debugger Version 6.6.0003.5 Copyright
> (c) Microsoft Corporation. All rights reserved.
>
> *** wait with pending attach
> Symbol search path is:
> srv*D:\MSWebSymbols*http://msdl.microsoft.com/download/symbols
> Executable search path is:
> ModLoad: 01000000 01066000 regedit.exe
> Symbol search path is:
> srv*D:\MSWebSymbols*http://msdl.microsoft.com/download/symbols
> Executable search path is:
> ERROR: Unable to find system thread 42C
> ERROR: The thread being debugged has either exited or cannot be
> accessed
> ERROR: Many commands will not work properly Create process
unable to
> locate process or thread 298:42c
>
> Definitively there is something going wrong. Perhaps WinDbg ignored
> options that I specified in command line. It seems to me
that it is a
> bug.
>
> By the way, could Microsoft add equivalents of -pr -pb options that
> are present for command line into user interface in window
that opened
> after user chose “Attach to a Process”
> option in WinDbg?
>
>
> Well, I ignored this strange message and pressed g (Go) in
WinDbg. I
> received following output in WinDbg:
> 0:???> g
> WARNING: The debugger does not have a current process or thread
> WARNING: Many commands will not work
> ERROR: Unable to find system thread 42C
> ERROR: The thread being debugged has either exited or cannot be
> accessed
> ERROR: Many commands will not work properly
> ModLoad: 7c900000 7c9b0000 <no_process>
> > ERROR: Unable to find system thread 42C
> > ERROR: The thread being debugged has either exited or cannot be
> > accessed
> > ERROR: Many commands will not work properly
> > ModLoad: 7c800000 7c8f4000 <no_process>
> > Break-in sent, waiting 30 seconds…
> >
> > I not waited 30 seconds - I just pressed “Break” in WinDbg.
> I received
> > following output:
> >
> > (298.5f4): Break instruction exception - code 80000003 (first
> > chance) eax=7ffdf000 ebx=00000001 ecx=00000002 edx=00000003
> > esi=00000004
> > edi=00000005
> > eip=7c901230 esp=001cffcc ebp=001cfff4 iopl=0 nv up
> > ei pl zr na
> > po
> > nc
> > cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
> > efl=00000246
> > no_process!DbgBreakPoint:
> > 7c901230 cc int 3
> >
> > Just to be sure that RegEdit threads are not suspended I used
> > following
> > command:
> >
> > 0:002> ~*m
> >
> >
> > Then I again pressed g (Go) in WinDbg and received following output:
> >
> > 0:002> g
> > (298.504): Access violation - code c0000005 (first chance) First
> > chance exceptions are reported before any exception handling.
> > This exception may be expected and handled.
> > eax=00000000 ebx=00000000 ecx=010000e0 edx=7c90eb94 esi=0006fa30
> > edi=7c80b529
> > eip=4dc2537c esp=0007ff2c ebp=0007ffc0 iopl=0 nv up
> > ei pl zr na
> > po
> > nc
> > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
> > efl=00010246
> > 4dc2537c ?? ???
> >
> > Further application’s execution is not possible. Application was
> > terminated on target.
> >
> >
> > It seems to me that user mode remote debugging scenario
> with initially
> > suspended application should be improved a lot.
> >
> > Best regards / Mit freundlichen Gruessen
> >
> > Oleksiy Shatylo
> > Senior Software Engineer
> >
> > Nero AG
> > Im Stoeckmaedle 18
> > 76307 Karlsbad
> > Germany
> >
> > E-mail xxxxx@nero.com
> >
> > NERO - BECAUSE TECHNOLOGY COUNTS
> > www.nero.com
> >
> >
> > This e-mail may contain confidential and/or privileged
> information. If
> > you are not the intended recipient (or have received this e-mail in
> > error) please notify the sender immediately and destroy
> this e-mail.
> > Any unauthorised copying, disclosure or distribution of the
> material
> > in this e-mail is strictly forbidden.
> > *********************************************************
> >
> >
> >
> > —
> > You are currently subscribed to windbg as:
> > xxxxx@winse.microsoft.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
> >
> >
> > —
> > You are currently subscribed to windbg as: unknown lmsubst tag
> > argument: ‘’
> > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> >
> >
>
>
>
> —
> You are currently subscribed to windbg as:
> xxxxx@winse.microsoft.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
>
>
>
> —
> You are currently subscribed to windbg as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
—
You are currently subscribed to windbg as: xxxxx@stonestreetone.com To
unsubscribe send a blank email to xxxxx@lists.osr.com</no_process></no_process>