Thanks David - at least it isn’t so obviously brain-damaged that someone
was able to point it out to me.
Like you, I suspected some strange configuration problem. I uninstalled
WinDBG, rebooted (nothing like a clean slate), reinstalled and observed
the same behavior. Of course, the frustrating part is that I just
wanted to grab a crash dump to submit against the application (a
commercial application package crashing in a highly reproducible
fashion). I spent an hour playing around with it and was unable to get
anything except this error. Of course, it was one of those wonderful
situations where you end up down a rat-hole (debugging the debugger,
rather than doing the task that has to get done today…)
Like you, I am running on an XPSP2 system; all current patches
installed. System is a P4 Extreme system (HT enabled), 2GB memory,
100GB HD. I use the debugger on this system all the time without
problems - but I’m debugging kernel mode, not user mode. I just assumed
I must be missing some subtlety of the user mode debugging environment.
I’ll see if I can reproduce the problem on another system. I’d been
looking for an excuse to reinstall my system anyway, so perhaps it is
now time to back up the entire machine and do a clean install. No doubt
the problem will go away (actually, that is one of the suggested
solutions on the support website for the application in question…)
But, I suspect this means I’m just not destined to do user mode
debugging. I’ll stick to the kernel, where things make sense. 
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:</http:>
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Holcomb
Sent: Sunday, February 13, 2005 2:42 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] User mode dumps?
I tried setting windbg as my postmortem debugger (windbg -I) and then
launched a user mode app and forced it to crash. I did not have a
problem using .dump /ma to create a dump.
You might want to check your debugger configuration to make sure you
have the right debugger binaries in place. If you ran the MSI install,
then I can’t explain it, but if you copied the debugger binaries from
another location, or tried to copy them over an existing installation
and some of the binaries were in use, you may have a mix-match of
different version binaries or something.
0:002> .dump /ma test.dmp
Creating test.dmp - mini user dump
Dump successfully written
0:002> version
Windows XP Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: SingleUserTS
kernel32.dll version: 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)
Debug session time: Sun Feb 13 09:23:33.515 2005 (GMT-8)
System Uptime: 1 days 16:07:12.083
Process Uptime: 0 days 0:01:38.890
Kernel time: 0 days 0:00:00.171
User time: 0 days 0:00:00.031
Live user mode:
command line: ‘“C:\dbg.6.4.7.2\windbg.exe” -p 5800 -e 1920 -g’ Debugger
Process 0x17E4
dbgeng: image 6.4.0007.2, built Fri Jan 14 13:36:58 2005
[path: C:\dbg.6.4.7.2\dbgeng.dll]
dbghelp: image 6.4.0007.1, built Wed Jan 12 11:23:59 2005
[path: C:\dbg.6.4.7.2\dbghelp.dll]
DIA version: 40416
Extension DLL search Path:
C:\dbg.6.4.7.2\winext;C:\dbg.6.4.7.2\winext\arcade;C:\dbg.6.4.7.2\WINXP;
C:\dbg.6.4.7.2\pri;C:\dbg.6.4.7.2;C:\dbg.6.4.7.2\winext\arcade;C:\WINDOW
S\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\VDMSound
Extension DLL chain:
dbghelp: image 6.4.0007.1, API 6.0.6, built Wed Jan 12 11:23:59 2005
[path: C:\dbg.6.4.7.2\dbghelp.dll]
ext: image 6.4.0007.0, API 1.0.0, built Tue Jan 11 15:23:48 2005
[path: C:\dbg.6.4.7.2\winext\ext.dll]
exts: image 6.4.0007.0, API 1.0.0, built Tue Jan 11 15:23:34 2005
[path: C:\dbg.6.4.7.2\WINXP\exts.dll]
uext: image 6.4.0007.0, API 1.0.0, built Tue Jan 11 15:23:46 2005
[path: C:\dbg.6.4.7.2\winext\uext.dll]
ntsdexts: image 6.0.5027.0, API 1.0.0, built Mon Jan 10 15:02:58
2005
[path: C:\dbg.6.4.7.2\WINXP\ntsdexts.dll]
Of course, it could be something else entirely – as you can see I tried
my test on XP SP2. Maybe the problem is specific to W2K or W2K3 or
something… Or some environment setting may be confusing the debugger
engine into thinking it is in a live user mode crash, while some other
setting that the debugger checks is making the debugger think it is not
a live user mode crash.
I do see something odd in my extension DLL search path above…I don’t
know why the debugger is adding C:\dbg.6.4.7.2\winext\arcade to my
extension path. And it’s doing it twice! It doesn’t happen with the
6.2.13.1 debugger after simulating the same crash with the old debugger
set as the postmortem debugger:
0:001> version
Windows XP Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: SingleUserTS
kernel32.dll version: 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)
Debug session time: Sun Feb 13 10:00:19 2005
System Uptime: 1 days 16:43:58.198
Process Uptime: 0 days 0:01:02.578
Kernel time: 0 days 0:00:00.046
User time: 0 days 0:00:00.031
Live user mode:
command line: ‘“C:\dbg.6.2.13.1\windbg.exe” -p 4220 -e 1932 -g’
Debugger Process 0x17D0
dbgeng: image 6.2.0013.1, built Tue Jul 15 14:31:37 2003
[path: C:\dbg.6.2.13.1\dbgeng.dll]
dbghelp: image 6.2.0013.1, built Fri Jul 11 12:14:13 2003
[path: C:\dbg.6.2.13.1\dbghelp.dll]
DIA version: 30509
Extension DLL search Path:
C:\dbg.6.2.13.1\winext;C:\dbg.6.2.13.1\WINXP;C:\dbg.6.2.13.1\pri;C:\dbg.
62.13.1;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Progr
am Files\VDMSound
Extension DLL chain:
dbghelp: image 6.2.0013.1, API 6.0.6, built Fri Jul 11 12:14:13 2003
[path: C:\dbg.6.2.13.1\dbghelp.dll]
ext: image 6.2.0013.1, API 1.0.0, built Tue Jul 08 20:07:40 2003
[path: C:\dbg.6.2.13.1\winext\ext.dll]
exts: image 6.2.0013.0, API 1.0.0, built Tue Jul 08 20:07:39 2003
[path: C:\dbg.6.2.13.1\WINXP\exts.dll]
uext: image 6.2.0013.0, API 1.0.0, built Tue Jul 08 20:07:43 2003
[path: C:\dbg.6.2.13.1\winext\uext.dll]
ntsdexts: image 6.0.4028.0, API 1.0.0, built Wed Jul 02 18:34:48
2003
[path: C:\dbg.6.2.13.1\WINXP\ntsdexts.dll]
Version 5.1 (Build 2600: Service Pack 2) Uniprocessor Free
I can’t find any arcade references in my registry or my environment
variables that would explain where it is coming from.
----- Original Message -----
From: Tony Mason mailto:xxxxx
To: Kernel Debugging Interest List mailto:xxxxx
Sent: Sunday, February 13, 2005 8:32 AM
Subject: [windbg] User mode dumps?
I’ve always configured WinDBG as my postmortem debugger; with
the current version (6.4.7.2) when an application dies and I try to
create a minidump (“.dump /ma”) I just get the message:
0:000> .dump /ma
^ Syntax error in ‘.dump /ma’
So I go through the debugger documentation and it says this
should work. Falling back to just “.dump” still gives me the same
error. So I tried various options - “.dump /?” gives me help
information. My favorite was:
0:000> .dump /f
*****************************************************************
.dump /ma is the recommend method of creating a complete
memory dump
of a user mode process.
*******************************************************************
^ Syntax error in ‘.dump /f’
Tell me an alternative (the first one I used) and THEN tell me
that my command has a syntax error. I don’t create user mode dumps
often, but this has worked for me in the past. Has anyone on the list
seen this issue before, and if so can you tell me what dumb thing I’m
doing wrong?
Thanks!
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:</http:>
—
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: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx>