I’ve never tried using VS remote debugging with services. MSVSMON
appears to support only the “launch process” debug model – I don’t see
a way to use it with the IFEO key, which has always been the most
reliable way to debug services. So it looks like the only option is
installing VS.
I know you’re working on managed code, so this won’t help much, but
remote debugging with cdb.exe and the IFEO key is really great. Set the
“Debugger” value to something like “cdb -server tcp:port=4000 -G”, start
the service, then connect with windbg (or whatever) from your dev
machine, and hit go.
If only MSVSMON could work the same as cdb…
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Monday, May 22, 2006 2:19 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Managed code debugging, redux
Arlie, any wicked and evil thought’s I have ever directed your way I
totally revoke and disown. 
Thank you for the information. I do assume that overall this will
require VS 2005 installed on the system where the service resides? I’ve
been doing this using VS Remote Debug since I wanted to keep the target
as unpolluted as possible.
Gary G. Little
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arlie Davis
Sent: Monday, May 22, 2006 4:05 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Managed code debugging, redux
VS can debug start path of services, with a little effort.
Use the “Image File Execution Options” registry key, and set the
“Debugger” value to “c:.…\devenv.exe /run c:\some\path\myproject.sln”.
Configure the service to run as LocalSystem, and to have interactive
access. i.e. “sc config myservice type= own type= interact” (sc’s picky
about spaces). Start the service. VS should start, load your project,
run it, and it should be able to contact the SCM and do it’s start-up
path processing.
It works, but you may need to do some dancing. VS2005 will start in the
LocalSystem account, and so will want to do it’s “What kind of
environment do you want?” prompt and all sorts of other initialization.
The worst part about it is that the SCM gets impatient and terminates
the process it spawned if this takes too long – which usually kills
devenv.exe itself. I think there’s a reg key that allows you to tune
that interval; probably requires a reboot.
If you really want to use VS2005 to debug service startup, it does work.
I just did it on a system service (RSVP QoS service / rsvp.exe). You’ll
have to get used to closing / reopening devenv for every service
start/stop, but that’s just another rough edge. (Yes, I know rsvp.exe
doesn’t contain any managed code. But it’s just as valid.)
You *can* launch devenv.exe with /run c:.…\foo.exe, but I recommend
using a project file, because then you can specify command-line
arguments, the debug mode (mixed!), etc. You can either point it to the
.sln file that you develop against, or if that takes too long to load,
you can create a debug-only .sln file. Run VS2005, File, Open Project,
and select your service executable (not the project). Now click Save
All (the easiest way I’ve found to provoke the “save project” dialog),
and save this .sln file as your debug-only .sln file. Specify the path
to this file in your Image File Execution Options / Debugger key, and
you should be able to do it.
– arlie
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Monday, May 22, 2006 1:39 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Managed code debugging, redux
I’ve used WinDbg many times to debug user apps, but admittedly it nearly
always required setting a BP in the dispatch function of the driver I
was debugging, reloading symbols to resolve the apps symbols, and then
setting a breakpoint in the user app.
The reason for attempting to use WinDbg is an attempt to go where the
Visual Studios debugger will not take you, or you have to kludge a
bastardized entry point. OnStart in a managed code service is a REALLY
nice place to visit every now and then, but the VS studio won’t take you
there. Well you can rape your code and call it directly, as is suggested
by the docs, but that does not permit real runtime debunking of
problems.
Hence I was hoping the Debugging Tools for Windows would permit that.
Right now I’m using a combination of WinDbg to observe debug print
statements from those “nether regions” VS cannot reach, comments written
to the Application Event log, and Visual Studios Remote debugging to
step into the code after I attach to the running code. Of course the
area I need to see debug right now is the “nether” regions.
Gary G. Little
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Monday, May 22, 2006 2:05 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Managed code debugging, redux
sos is looking for mscorwks in the target’s module list, not in the
extension chain.
windbg has no managed debugging support, so you’re starting with a rough
experience. All you get is the CLR team’s sos extension, nothing
integrated. Add on top of that the fact that using kd for user-mode
debugging causes all sorts of difficulties, mostly due to paged-out
memory and getting the right process context) and you’re going to need
some luck for things to work smoothly.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Monday, May 22, 2006 11:56 AM
To: Kernel Debugging Interest List
Subject: [windbg] Managed code debugging, redux
Here is a dump of what I get when I attempted to set a breakpoint in
managed code:
kd> !BPMD SeaTdtSvc!SeaTdtSvc::SeaTdtSvcWinService::WorkerThread
Failed to find runtime DLL (mscorwks.dll), 0x80004005 Extension commands
need mscorwks.dll in order to have something to do.
However, when I look to see what is there, son of a gun I find what
WinDbg says it can’t find: mscorwks.dll.
kd> .chain
Extension DLL search Path:
C:\Program Files\Debugging Tools for Windows
64-bit\winext;C:\Program Files\Debugging Tools for Windows
64-bit\winext\arcade;C:\Program Files\Debugging Tools for Windows
64-bit\WINXP;C:\Program Files\Debugging Tools for Windows
64-bit\pri;C:\Program Files\Debugging Tools for Windows
64-bit;C:\Program Files\Debugging Tools for Windows
64-bit\winext\arcade;C:\Program Files\Support
Tools;c:\Perl\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wb
em
;C:\Program Files (x86)\Microsoft SQL Server\90\Tools\binn;C:\Program
Files (x86)\cvsnt;C:\Program Files (x86)\Resource Kit;C:\Program
Files\Microsoft Visual Studio 8\VC\bin;C:\Program Files (x86)\Microsoft
Visual Studio 8\VC\bin;C:\Program Files\Debugging Tools for Windows
64-bit Extension DLL chain:
\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\mscorwks: image
2.0.50727.42, built Fri Sep 23 04:17:48 2005
[path:
c:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\mscorwks.dll]
c:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\mscorwks.dll: image
2.0.50727.42, built Fri Sep 23 04:17:48 2005
[path:
c:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\mscorwks.dll]
c:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\SOS.dll: image
2.0.50727.42, API 1.0.0, built Fri Sep 23 04:21:34 2005
[path: c:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\SOS.dll]
dbghelp: image 6.6.0003.5, API 6.0.6, built Wed Jan 18 17:12:01 2006
[path: C:\Program Files\Debugging Tools for Windows
64-bit\dbghelp.dll]
ext: image 6.6.0003.5, API 1.0.0, built Wed Jan 18 17:11:45 2006
[path: C:\Program Files\Debugging Tools for Windows
64-bit\winext\ext.dll]
exts: image 6.6.0003.5, API 1.0.0, built Wed Jan 18 17:11:34 2006
[path: C:\Program Files\Debugging Tools for Windows
64-bit\WINXP\exts.dll]
kext: image 6.6.0003.5, API 1.0.0, built Wed Jan 18 17:11:37 2006
[path: C:\Program Files\Debugging Tools for Windows
64-bit\winext\kext.dll]
kdexts: image 6.0.5278.0, API 1.0.0, built Wed Jan 18 17:20:58 2006
[path: C:\Program Files\Debugging Tools for Windows
64-bit\WINXP\kdexts.dll]
Frankly I have tried for weeks now to use Windows debugging tools to
debug a managed service, and so far the best I can do is to capture the
output from debugprint statements in my source.
My host is Windows XP x64, running Debugging Tools for Windows 64 bit.
My target is Windows XP SP2. My service is a C++ service project built
using Visual Studio 2005 Team Edition for Architects. The service is
loaded, started and running. The particular breakpoint is in a thread
started by the service.
Gary G. Little
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@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@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com