If you type ‘.reload .fvu’ in command line it closes without any message.
-htfv
This does not repro for me. You must be doing something else too that
is pre-empting the failure.
0:000> .reload .fvu
Module “.fvu” was not found in the module list.
Debugger will attempt to load module “.fvu” by guessing the base
address.
Please provide the full image name, including the extension (i.e.
kernel32.dll) for more reliable results.
Unable to add module at 00000000
Can you double-check your repro steps and verify whether it happens when
you use one of the console debuggers too (ntsd, cdb, kd)?
-----Original Message-----
From: Alexey Logachyov [mailto:xxxxx@vba.com.by]
Sent: Tuesday, September 24, 2002 7:25 AM
To: Kernel Debugging Interest List
Subject: [windbg] WinDBG 6.0.17.0 bug
If you type ‘.reload .fvu’ in command line it closes without any
message.
-htfv
You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
I debugged a bugcheck and I wanted to release .pdb files to be able to
recompile my driver. I mistyped and bang! Immediately after that I restarted
WinDBG 2 times just to check and the problem persisted.
Currently I’m debugging MUTEX_ALREADY_OWNED(bf) BSOD and the problem is
still here. Target OS is Windows 2000 SP2 checked build (build 2195). Host
OS - Windows XP build 2600 with all updates from windowsupdate.microsoft.com
installed (no SP1).
-htfv
----- Original Message -----
From: “David Holcomb”
To: “Kernel Debugging Interest List”
Sent: Tuesday, September 24, 2002 7:23 PM
Subject: [windbg] RE: WinDBG 6.0.17.0 bug
This does not repro for me. You must be doing something else too that
is pre-empting the failure.
0:000> .reload .fvu
Module “.fvu” was not found in the module list.
Debugger will attempt to load module “.fvu” by guessing the base
address.
Please provide the full image name, including the extension (i.e.
kernel32.dll) for more reliable results.
Unable to add module at 00000000
Can you double-check your repro steps and verify whether it happens when
you use one of the console debuggers too (ntsd, cdb, kd)?
-----Original Message-----
From: Alexey Logachyov [mailto:xxxxx@vba.com.by]
Sent: Tuesday, September 24, 2002 7:25 AM
To: Kernel Debugging Interest List
Subject: [windbg] WinDBG 6.0.17.0 bug
If you type ‘.reload .fvu’ in command line it closes without any
message.
-htfv
—
You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to windbg as: xxxxx@vba.com.by
To unsubscribe send a blank email to %%email.unsub%%
Why don’t you load windbg under the debugger and see if you catch an AV.
If so, you can create a dump with .dump /mfh and zipt or CAB it up and
send to xxxxx@microsoft.com. Thanks!
-----Original Message-----
From: Alexey Logachyov [mailto:xxxxx@vba.com.by]
Sent: Wednesday, September 25, 2002 1:23 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: WinDBG 6.0.17.0 bug
I debugged a bugcheck and I wanted to release .pdb files to be able to
recompile my driver. I mistyped and bang! Immediately after that I
restarted WinDBG 2 times just to check and the problem persisted.
Currently I’m debugging MUTEX_ALREADY_OWNED(bf) BSOD and the problem is
still here. Target OS is Windows 2000 SP2 checked build (build 2195).
Host OS - Windows XP build 2600 with all updates from
windowsupdate.microsoft.com installed (no SP1).
-htfv
----- Original Message -----
From: “David Holcomb”
To: “Kernel Debugging Interest List”
Sent: Tuesday, September 24, 2002 7:23 PM
Subject: [windbg] RE: WinDBG 6.0.17.0 bug
This does not repro for me. You must be doing something else too that
is pre-empting the failure.
0:000> .reload .fvu
Module “.fvu” was not found in the module list.
Debugger will attempt to load module “.fvu” by guessing the base
address.
Please provide the full image name, including the extension (i.e.
kernel32.dll) for more reliable results.
Unable to add module at 00000000
Can you double-check your repro steps and verify whether it happens when
you use one of the console debuggers too (ntsd, cdb, kd)?
-----Original Message-----
From: Alexey Logachyov [mailto:xxxxx@vba.com.by]
Sent: Tuesday, September 24, 2002 7:25 AM
To: Kernel Debugging Interest List
Subject: [windbg] WinDBG 6.0.17.0 bug
If you type ‘.reload .fvu’ in command line it closes without any
message.
-htfv
—
You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to windbg as: xxxxx@vba.com.by
To unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
I can reproduce this as well by doing the following:
kd> .reload -fvu
kd> .reload .fvu
The debugger freezes (the box next to the command line remains grey) for
about 3 seconds, then the debugger closes.
I’ll send the dump to the address you requested…
The stack trace from a WinDBG attached to the WinDBG process that
crashed looks like an exception was raised, WinDBG caught the failure
and then terminated itself:
eax=00000058 ebx=00000000 ecx=00000001 edx=00000000 esi=77f7f3c3
edi=00000003
eip=7ffe0304 esp=0095b064 ebp=0095b15c iopl=0 nv up ei pl nz na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
efl=00000202
SharedUserData!SystemCallStub+4:
7ffe0304 c3 ret
0:001> kv
ChildEBP RetAddr Args to Child
0095b060 77f7f3cf 77e75ca4 ffffffff 00000003
SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
0095b064 77e75ca4 ffffffff 00000003 00000000
ntdll!ZwTerminateProcess+0xc (FPO: [2,0,0])
0095b15c 77e75cc6 00000003 77e8f3b0 ffffffff kernel32!_ExitProcess+0x57
(FPO: [Non-Fpo])
0095b170 77c379c8 00000003 77c37ad9 00000003 kernel32!ExitProcess+0x11
(FPO: [Non-Fpo])
0095b178 77c37ad9 00000003 77c5c888 77c37afc
msvcrt!__crtExitProcess+0x2f (FPO: [1,0,0])
0095b184 77c37afc 00000003 00000001 0095b1a0 msvcrt!_cinit+0xe4 (FPO:
[2,0,1])
0095b194 77c3350c 00000003 0095cb38 77c5acc0 msvcrt!_exit+0xe (FPO: [1,0,1])
0095b1dc 77c34cbe 00000016 00000018 00a51268 msvcrt!raise+0xae (FPO:
[Non-Fpo])
0095b254 77f516f5 00000045 00081378 00080000 msvcrt!abort+0xe (FPO: [0,0,0])
0095b51c 028217cf 02803820 028037dc 0000017c
ntdll!RtlpAllocateFromHeapLookaside+0x42 (FPO: [Non-Fpo])
0095b534 02829a84 00000000 0095b7b8 0095b9c1
dbghelp!CreateSymbolPath+0x4f (FPO: [Non-Fpo])
0095bcf8 0282be79 0095bd14 0031b550 0033c47e
dbghelp!FindDebugInfoFileEx+0x3b4 (FPO: [Non-Fpo])
0095be24 0282a954 0033c238 0095cb38 00a51268 dbghelp!GetDebugData+0x1a9
(FPO: [Non-Fpo])
0095bfc8 0282af6e f0f0f0f0 00280688 0095cb38 dbghelp!modload+0x264 (FPO:
[Non-Fpo])
0095c278 02825626 f0f0f0f0 0098104d 00980fcd dbghelp!LoadModule+0x45e
(FPO: [Non-Fpo])
0095c2dc 020cb948 f0f0f0f0 00000000 0098104d
dbghelp!SymLoadModuleEx+0x56 (FPO: [Non-Fpo])
0095c72c 02123917 0095c8e8 00000001 0095cb4c
dbgeng!ProcessInfo::AddImage+0x908 (FPO: [Non-Fpo])
0095cb90 020948b0 00268a08 0095cbfb 00000000
dbgeng!TargetInfo::Reload+0x14f7 (FPO: [Non-Fpo])
0095d3e8 020bfac9 002659f8 0095e609 02188648 dbgeng!ParseBangCmd+0x440
(FPO: [Non-Fpo])
0095e580 020c1668 002659f8 00000000 0095eef8
dbgeng!ProcessCommands+0x5d9 (FPO: [Non-Fpo])
hope this helps…
sean
David Holcomb wrote:
Why don’t you load windbg under the debugger and see if you catch an AV.
If so, you can create a dump with .dump /mfh and zipt or CAB it up and
send to xxxxx@microsoft.com. Thanks!-----Original Message-----
From: Alexey Logachyov [mailto:xxxxx@vba.com.by]
Sent: Wednesday, September 25, 2002 1:23 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: WinDBG 6.0.17.0 bugI debugged a bugcheck and I wanted to release .pdb files to be able to
recompile my driver. I mistyped and bang! Immediately after that I
restarted WinDBG 2 times just to check and the problem persisted.Currently I’m debugging MUTEX_ALREADY_OWNED(bf) BSOD and the problem is
still here. Target OS is Windows 2000 SP2 checked build (build 2195).
Host OS - Windows XP build 2600 with all updates from
windowsupdate.microsoft.com installed (no SP1).-htfv
----- Original Message -----
From: “David Holcomb”
>To: “Kernel Debugging Interest List”
>Sent: Tuesday, September 24, 2002 7:23 PM
>Subject: [windbg] RE: WinDBG 6.0.17.0 bug
>
>
>This does not repro for me. You must be doing something else too that
>is pre-empting the failure.
>
>0:000> .reload .fvu
>
>
>Module “.fvu” was not found in the module list.
>Debugger will attempt to load module “.fvu” by guessing the base
>address.
>
>Please provide the full image name, including the extension (i.e.
>kernel32.dll) for more reliable results.
>Unable to add module at 00000000
>
>Can you double-check your repro steps and verify whether it happens when
>you use one of the console debuggers too (ntsd, cdb, kd)?
>
>-----Original Message-----
>From: Alexey Logachyov [mailto:xxxxx@vba.com.by]
>Sent: Tuesday, September 24, 2002 7:25 AM
>To: Kernel Debugging Interest List
>Subject: [windbg] WinDBG 6.0.17.0 bug
>
>
>If you type ‘.reload .fvu’ in command line it closes without any
>message.
>
>-htfv
>
>
>
>
>—
>You are currently subscribed to windbg as: xxxxx@microsoft.com To
>unsubscribe send a blank email to %%email.unsub%%
>
>
>—
>You are currently subscribed to windbg as: xxxxx@vba.com.by
>To unsubscribe send a blank email to %%email.unsub%%
>
>
>
>
>—
>You are currently subscribed to windbg as: xxxxx@microsoft.com To
>unsubscribe send a blank email to %%email.unsub%%
>
>
>—
>You are currently subscribed to windbg as: xxxxx@stg.com
>To unsubscribe send a blank email to %%email.unsub%%
>
>
OK, following my previous email where a process was about to exit and I
wanted to do a dumpfile…
I must be missing something really simple here:
0:001> .dump /mfh
^ Syntax error in ‘.dump /mfh’
0:001> .dump /mf /mh
^ Syntax error in ‘.dump /mf /mh’
0:001> .dump /mf
^ Syntax error in ‘.dump /mf’
0:001> .dump /mh
^ Syntax error in ‘.dump /mh’
0:001> .dump /?
Usage: .dump [options] filename
Options are:
/a - Create dumps for all processes (requires -u)
/b[a] - Package dump in a CAB and delete dump
/c - Add a comment (not supported in all formats)
/f - Create a full dump
/m[dfhiprRuw] - Create a minidump (default)
/o - Overwrite any existing file
/u - Append unique identifier to dump name
Use “.hh .dump” or open debugger.chm in the debuggers directory to get
detailed documentation on this command.
0:001> .dump -mfh
^ Syntax error in ‘.dump -mfh’
0:001> .dump /f seandump
Creating seandump - user full dump
0:001> .dump /mfh
^ Syntax error in ‘.dump /mfh’
0:001> .dump /m fh
Creating fh - mini user dump
0:001> .dump /m seanminidump
Creating seanminidump - mini user dump
The help file also says that the ‘f’ and ‘h’ options are valid for
“.dump /m”:
<---- snip ---->
/m[MiniOptions]
Causes the debugger to create a Small Memory Dump (in kernel mode) or a
minidump (in user mode). If neither /f nor /m is specified, /m is the
default.
In user mode, /m can be followed with additional MiniOptions that
specify extra data that should be included in the dump. If no
MiniOptions are included, the dump will include module, thread, and
stack information, but no additional data. Any of the following
MiniOptions can be added to change the contents of the dump file; they
are case-sensitive.
<---- snip ---->
Is the command line parser screwing up or am I? Or can I not create a
dump with these options at this point (because the process is exiting
and may have already had it’s associated memory freed)?
sean
David Holcomb wrote:
>Why don’t you load windbg under the debugger and see if you catch an AV.
>If so, you can create a dump with .dump /mfh and zipt or CAB it up and
>send to xxxxx@microsoft.com. Thanks!
>osr.com
>
>
Can you verify with the “version” command what version of everything you
have loaded? It sounds like you have an older version of dbgeng.dll
than the one that shipped in 6.0.17.
-----Original Message-----
From: Sean Bullington [mailto:xxxxx@stg.com]
Sent: Wednesday, September 25, 2002 9:46 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: WinDBG 6.0.17.0 bug
OK, following my previous email where a process was about to exit and I
wanted to do a dumpfile…
I must be missing something really simple here:
0:001> .dump /mfh
^ Syntax error in ‘.dump /mfh’
0:001> .dump /mf /mh
^ Syntax error in ‘.dump /mf /mh’
0:001> .dump /mf
^ Syntax error in ‘.dump /mf’
0:001> .dump /mh
^ Syntax error in ‘.dump /mh’
0:001> .dump /?
Usage: .dump [options] filename
Options are:
/a - Create dumps for all processes (requires -u)
/b[a] - Package dump in a CAB and delete dump
/c - Add a comment (not supported in all formats)
/f - Create a full dump
/m[dfhiprRuw] - Create a minidump (default)
/o - Overwrite any existing file
/u - Append unique identifier to dump name
Use “.hh .dump” or open debugger.chm in the debuggers directory to get
detailed documentation on this command.
0:001> .dump -mfh
^ Syntax error in ‘.dump -mfh’
0:001> .dump /f seandump
Creating seandump - user full dump
0:001> .dump /mfh
^ Syntax error in ‘.dump /mfh’
0:001> .dump /m fh
Creating fh - mini user dump
0:001> .dump /m seanminidump
Creating seanminidump - mini user dump
The help file also says that the ‘f’ and ‘h’ options are valid for
“.dump /m”:
<---- snip ---->
/m[MiniOptions]
Causes the debugger to create a Small Memory Dump (in kernel mode) or a
minidump (in user mode). If neither /f nor /m is specified, /m is the
default.
In user mode, /m can be followed with additional MiniOptions that
specify extra data that should be included in the dump. If no
MiniOptions are included, the dump will include module, thread, and
stack information, but no additional data. Any of the following
MiniOptions can be added to change the contents of the dump file; they
are case-sensitive.
<---- snip ---->
Is the command line parser screwing up or am I? Or can I not create a
dump with these options at this point (because the process is exiting
and may have already had it’s associated memory freed)?
sean
David Holcomb wrote:
>Why don’t you load windbg under the debugger and see if you catch an
>AV. If so, you can create a dump with .dump /mfh and zipt or CAB it up
>and send to xxxxx@microsoft.com. Thanks! osr.com
>
>
—
You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
0:009> version
Windows XP Version 2600 UP Free x86 compatible
Product: WinNt, suite: SingleUserTS
kernel32.dll version: 5.1.2600.0 (xpclient.010817-1148)
Debug session time: Wed Sep 25 12:17:24 2002
System Uptime: 27 days 1:13:26.810
Process Uptime: 0 days 0:20:44.395
Live user mode:
command line: '“C:\windbg\windbg.exe” ’ Debugger Process 0x6E0
dbgeng: image 6.0.0017.0, built Tue Jun 04 14:21:55 2002
[path: C:\windbg\dbgeng.dll]
dbghelp: image 6.0.0017.0, built Fri May 31 18:54:47 2002
[path: C:\windbg\dbghelp.dll]
DIA version: 2140
Extension DLL search Path:
C:\windbg\winext;C:\windbg\pri;C:\windbg\WINXP;C:\windbg;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\PROGRA~1\NcFTP;“C:\Program
Files\GNU\WinCvs
1.2”;c:\vim\vim60;C:\msvc32\Tools\WinNT;C:\msvc32\MSDev98\Bin;C:\msvc32\Tools;C:\Microsoft
Visual Studio\VC98\bin;C:\Program Files\Intel\edb50;C:\Program
Files\Intel\Compiler50\ia32\bin;D:\Microsoft Visual
Studio\Common\Tools\WinNT;D:\Microsoft Visual
Studio\Common\MSDev98\Bin;D:\Microsoft Visual
Studio\Common\Tools;D:\Microsoft Visual Studio\VC98\bin
Extension DLL chain:
dbgeng: image 6.0.0017.0, built Tue Jun 04 14:21:55 2002
[path: C:\windbg\dbgeng.dll]
dbghelp: image 6.0.0017.0, API 5.2.6, built Fri May 31 18:54:47 2002
[path: C:\windbg\dbghelp.dll]
ext: image 6.0.0017.0, API 1.0.0, built Fri May 31 18:54:39 2002
[path: C:\windbg\winext\ext.dll]
exts: image 6.0.0017.0, API 1.0.0, built Fri May 31 18:54:39 2002
[path: C:\windbg\WINXP\exts.dll]
uext: image 6.0.0017.0, API 1.0.0, built Fri May 31 18:54:40 2002
[path: C:\windbg\winext\uext.dll]
ntsdexts: image 5.2.3639.0, API 1.0.0, built Fri May 31 18:32:22 2002
[path: C:\windbg\WINXP\ntsdexts.dll]
Version 5.1 (Build 2600) Uniprocessor Free
0:009> .dump /mfh
^ Syntax error in ‘.dump /mfh’
The versions seem to match… the ntsdexts.dll version is low, but the
build date is the same… but the build date for dbgeng.dll seems more
recent than the others…
sean
David Holcomb wrote:
>Can you verify with the “version” command what version of everything you
>have loaded? It sounds like you have an older version of dbgeng.dll
>than the one that shipped in 6.0.17.
>
>
n/m. It *was* something really simple: You must specify a filename, DUH!
A co-worker caught me on that one.
sigh. Next time I’ll pay closer attention to the help info I paste 
sean
David Holcomb wrote:
Can you verify with the “version” command what version of everything you
have loaded? It sounds like you have an older version of dbgeng.dll
than the one that shipped in 6.0.17.
Sorry I didn’t see the obvious before.
Usage: .dump [options] filename
Try .dump /mfh mydump.dmp
-----Original Message-----
From: David Holcomb
Sent: Wednesday, September 25, 2002 10:06 AM
To: ‘Kernel Debugging Interest List’
Subject: RE: [windbg] RE: WinDBG 6.0.17.0 bug
Can you verify with the “version” command what version of everything you
have loaded? It sounds like you have an older version of dbgeng.dll
than the one that shipped in 6.0.17.
-----Original Message-----
From: Sean Bullington [mailto:xxxxx@stg.com]
Sent: Wednesday, September 25, 2002 9:46 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: WinDBG 6.0.17.0 bug
OK, following my previous email where a process was about to exit and I
wanted to do a dumpfile…
I must be missing something really simple here:
0:001> .dump /mfh
^ Syntax error in ‘.dump /mfh’
0:001> .dump /mf /mh
^ Syntax error in ‘.dump /mf /mh’
0:001> .dump /mf
^ Syntax error in ‘.dump /mf’
0:001> .dump /mh
^ Syntax error in ‘.dump /mh’
0:001> .dump /?
Usage: .dump [options] filename
Options are:
/a - Create dumps for all processes (requires -u)
/b[a] - Package dump in a CAB and delete dump
/c - Add a comment (not supported in all formats)
/f - Create a full dump
/m[dfhiprRuw] - Create a minidump (default)
/o - Overwrite any existing file
/u - Append unique identifier to dump name
Use “.hh .dump” or open debugger.chm in the debuggers directory to get
detailed documentation on this command.
0:001> .dump -mfh
^ Syntax error in ‘.dump -mfh’
0:001> .dump /f seandump
Creating seandump - user full dump
0:001> .dump /mfh
^ Syntax error in ‘.dump /mfh’
0:001> .dump /m fh
Creating fh - mini user dump
0:001> .dump /m seanminidump
Creating seanminidump - mini user dump
The help file also says that the ‘f’ and ‘h’ options are valid for
“.dump /m”:
<---- snip ---->
/m[MiniOptions]
Causes the debugger to create a Small Memory Dump (in kernel mode) or a
minidump (in user mode). If neither /f nor /m is specified, /m is the
default.
In user mode, /m can be followed with additional MiniOptions that
specify extra data that should be included in the dump. If no
MiniOptions are included, the dump will include module, thread, and
stack information, but no additional data. Any of the following
MiniOptions can be added to change the contents of the dump file; they
are case-sensitive.
<---- snip ---->
Is the command line parser screwing up or am I? Or can I not create a
dump with these options at this point (because the process is exiting
and may have already had it’s associated memory freed)?
sean
David Holcomb wrote:
>Why don’t you load windbg under the debugger and see if you catch an
>AV. If so, you can create a dump with .dump /mfh and zipt or CAB it up
>and send to xxxxx@microsoft.com. Thanks! osr.com
>
>
—
You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
This problem is fixed in the next debugger package. It only happens
when the module’s filename is empty. (.fvu is interpreted as the
extension)
-----Original Message-----
From: Sean Bullington [mailto:xxxxx@stg.com]
Sent: Wednesday, September 25, 2002 9:29 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: WinDBG 6.0.17.0 bug
I can reproduce this as well by doing the following:
kd> .reload -fvu
kd> .reload .fvu
The debugger freezes (the box next to the command line remains grey) for
about 3 seconds, then the debugger closes.
I’ll send the dump to the address you requested…
The stack trace from a WinDBG attached to the WinDBG process that
crashed looks like an exception was raised, WinDBG caught the failure
and then terminated itself:
eax=00000058 ebx=00000000 ecx=00000001 edx=00000000 esi=77f7f3c3
edi=00000003
eip=7ffe0304 esp=0095b064 ebp=0095b15c iopl=0 nv up ei pl nz na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
efl=00000202
SharedUserData!SystemCallStub+4:
7ffe0304 c3 ret
0:001> kv
ChildEBP RetAddr Args to Child
0095b060 77f7f3cf 77e75ca4 ffffffff 00000003
SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
0095b064 77e75ca4 ffffffff 00000003 00000000
ntdll!ZwTerminateProcess+0xc (FPO: [2,0,0])
0095b15c 77e75cc6 00000003 77e8f3b0 ffffffff kernel32!_ExitProcess+0x57
(FPO: [Non-Fpo])
0095b170 77c379c8 00000003 77c37ad9 00000003 kernel32!ExitProcess+0x11
(FPO: [Non-Fpo])
0095b178 77c37ad9 00000003 77c5c888 77c37afc
msvcrt!__crtExitProcess+0x2f (FPO: [1,0,0])
0095b184 77c37afc 00000003 00000001 0095b1a0 msvcrt!_cinit+0xe4 (FPO:
[2,0,1])
0095b194 77c3350c 00000003 0095cb38 77c5acc0 msvcrt!_exit+0xe (FPO:
[1,0,1]) 0095b1dc 77c34cbe 00000016 00000018 00a51268 msvcrt!raise+0xae
(FPO:
[Non-Fpo])
0095b254 77f516f5 00000045 00081378 00080000 msvcrt!abort+0xe (FPO:
[0,0,0]) 0095b51c 028217cf 02803820 028037dc 0000017c
ntdll!RtlpAllocateFromHeapLookaside+0x42 (FPO: [Non-Fpo]) 0095b534
02829a84 00000000 0095b7b8 0095b9c1
dbghelp!CreateSymbolPath+0x4f (FPO: [Non-Fpo])
0095bcf8 0282be79 0095bd14 0031b550 0033c47e
dbghelp!FindDebugInfoFileEx+0x3b4 (FPO: [Non-Fpo])
0095be24 0282a954 0033c238 0095cb38 00a51268 dbghelp!GetDebugData+0x1a9
(FPO: [Non-Fpo])
0095bfc8 0282af6e f0f0f0f0 00280688 0095cb38 dbghelp!modload+0x264 (FPO:
[Non-Fpo])
0095c278 02825626 f0f0f0f0 0098104d 00980fcd dbghelp!LoadModule+0x45e
(FPO: [Non-Fpo])
0095c2dc 020cb948 f0f0f0f0 00000000 0098104d
dbghelp!SymLoadModuleEx+0x56 (FPO: [Non-Fpo])
0095c72c 02123917 0095c8e8 00000001 0095cb4c
dbgeng!ProcessInfo::AddImage+0x908 (FPO: [Non-Fpo])
0095cb90 020948b0 00268a08 0095cbfb 00000000
dbgeng!TargetInfo::Reload+0x14f7 (FPO: [Non-Fpo])
0095d3e8 020bfac9 002659f8 0095e609 02188648 dbgeng!ParseBangCmd+0x440
(FPO: [Non-Fpo])
0095e580 020c1668 002659f8 00000000 0095eef8
dbgeng!ProcessCommands+0x5d9 (FPO: [Non-Fpo])
hope this helps…
sean
David Holcomb wrote:
Why don’t you load windbg under the debugger and see if you catch an
AV. If so, you can create a dump with .dump /mfh and zipt or CAB it up
and send to xxxxx@microsoft.com. Thanks!-----Original Message-----
From: Alexey Logachyov [mailto:xxxxx@vba.com.by]
Sent: Wednesday, September 25, 2002 1:23 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: WinDBG 6.0.17.0 bugI debugged a bugcheck and I wanted to release .pdb files to be able to
recompile my driver. I mistyped and bang! Immediately after that I
restarted WinDBG 2 times just to check and the problem persisted.Currently I’m debugging MUTEX_ALREADY_OWNED(bf) BSOD and the problem is
still here. Target OS is Windows 2000 SP2 checked build (build 2195).
Host OS - Windows XP build 2600 with all updates from
windowsupdate.microsoft.com installed (no SP1).-htfv
----- Original Message -----
From: “David Holcomb”
>To: “Kernel Debugging Interest List”
>Sent: Tuesday, September 24, 2002 7:23 PM
>Subject: [windbg] RE: WinDBG 6.0.17.0 bug
>
>
>This does not repro for me. You must be doing something else too that
>is pre-empting the failure.
>
>0:000> .reload .fvu
>
>
>Module “.fvu” was not found in the module list.
>Debugger will attempt to load module “.fvu” by guessing the base
>address.
>
>Please provide the full image name, including the extension (i.e.
>kernel32.dll) for more reliable results.
>Unable to add module at 00000000
>
>Can you double-check your repro steps and verify whether it happens
>when you use one of the console debuggers too (ntsd, cdb, kd)?
>
>-----Original Message-----
>From: Alexey Logachyov [mailto:xxxxx@vba.com.by]
>Sent: Tuesday, September 24, 2002 7:25 AM
>To: Kernel Debugging Interest List
>Subject: [windbg] WinDBG 6.0.17.0 bug
>
>
>If you type ‘.reload .fvu’ in command line it closes without any
>message.
>
>-htfv
>
>
>
>
>—
>You are currently subscribed to windbg as: xxxxx@microsoft.com To
>unsubscribe send a blank email to %%email.unsub%%
>
>
>—
>You are currently subscribed to windbg as: xxxxx@vba.com.by
>To unsubscribe send a blank email to %%email.unsub%%
>
>
>
>
>—
>You are currently subscribed to windbg as: xxxxx@microsoft.com To
>unsubscribe send a blank email to %%email.unsub%%
>
>
>—
>You are currently subscribed to windbg as: xxxxx@stg.com
>To unsubscribe send a blank email to %%email.unsub%%
>
>
—
You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%