Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Issues with windbg - any experts available?

Status
Not open for further replies.

stduc

Programmer
Nov 26, 2002
1,903
GB
Sorry for the long post. In an attempt to make it easier to read I have made all my comments bold.

PC BSOD'd and generated a dump & a minidump.

If I analyse the minidump I get the following.



Microsoft (R) Windows Debugger Version 6.9.0003.113 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [D:\Memory Dumps\Athlon\Mini060508-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: D:\Debug_Symbols;SRV*D:\Debug_Symbols*Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt
Built by: 2600.xpsp_sp2_gdr.070227-2254
Kernel base = 0xe0b9b000 PsLoadedModuleList = 0xe0c1e620
Debug session time: Thu Jun 5 16:57:52.580 2008 (GMT+1)
System Uptime: 6 days 18:04:23.790
Loading Kernel Symbols
........................................................................................................................................................
Loading User Symbols
Loading unloaded module list
..................................................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {8b661e05, ff, 0, e0bb65a4}

Unable to load image \SystemRoot\System32\Drivers\aswMon2.SYS, Win32 error 0n2
*** WARNING: Unable to verify timestamp for aswMon2.SYS
*** ERROR: Module load completed but symbols could not be loaded for aswMon2.SYS
Probably caused by : aswMon2.SYS ( aswMon2+4d6a )

Followup: MachineOwner
---------

kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 8b661e05, memory referenced
Arg2: 000000ff, IRQL
Arg3: 00000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: e0bb65a4, address which referenced memory

Debugging Details:
------------------


READ_ADDRESS: 8b661e05

CURRENT_IRQL: ff

FAULTING_IP:
nt!ExpFindCurrentThread+68
e0bb65a4 8b4104 mov eax,dword ptr [ecx+4]

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

TRAP_FRAME: ecc792e4 -- (.trap 0xffffffffecc792e4)
ErrCode = 00000000
eax=e0c3c101 ebx=00000000 ecx=8b661e01 edx=00000000 esi=e0c3c0e1 edi=f7f4fda8
eip=e0bb65a4 esp=ecc79358 ebp=ecc79370 iopl=0 nv up di ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010082
nt!ExpFindCurrentThread+0x68:
e0bb65a4 8b4104 mov eax,dword ptr [ecx+4] ds:0023:8b661e05=????????
Resetting default scope

LAST_CONTROL_TRANSFER: from e0bb65a4 to e0ba587f

STACK_TEXT:
ecc792e4 e0bb65a4 badb0d00 00000000 00000000 nt!KiTrap0E+0x233
ecc79370 e0ba840f ecc79397 00000020 ecc793d4 nt!ExpFindCurrentThread+0x68
ecc79388 e0c31110 e0c3c0e1 ecc793b4 00000002 nt!ExAcquireResourceSharedLite+0x43
ecc793b8 e0bbf309 ecc793d4 00000001 ecc79848 nt!NtQueryInformationToken+0xed2
ecc793c8 e0bbefd6 ecc79444 ecc79410 00000001 nt!mbtowc+0x33
ecc79848 e0bb6a44 ecc79860 eb267b88 ecc79890 nt!_woutput+0x44b
ecc79880 eb267d6a e57e5718 eb267b88 00000043 nt!swprintf+0x30
WARNING: Stack unwind information not available. Following frames may be wrong.
ecc798b4 eb269200 f9452908 f89bbd50 f95537b8 aswMon2+0x4d6a
ecc799d0 eb2699a4 f89dceb8 f89dcc98 ecc79a07 aswMon2+0x6200
ecc79a08 eb26383c f9553700 009dcc98 e0ba77f7 aswMon2+0x69a4
ecc79b04 e0c34c14 f9553700 00000000 f89b1a78 aswMon2+0x83c
ecc79b3c e0c2b6b5 f9452908 00000000 f89b1a78 nt!IopParseFile+0x46
ecc79bc4 e0c2b49a 00004140 ecc79c04 00000040 nt!ObpLookupObjectName+0x119
ecc79c18 e0c33a23 00000000 00000000 c79cb001 nt!ObOpenObjectByName+0xeb
ecc79c94 e0c33af2 0b6cec40 00120089 0b6cec04 nt!IopCreateFile+0x407
ecc79cf0 e0c33c28 0b6cec40 00120089 0b6cec04 nt!IoCreateFile+0x8e
ecc79d30 e0ba27ec 0b6cec40 00120089 0b6cec04 nt!NtCreateFile+0x30
ecc79d30 7c90eb94 0b6cec40 00120089 0b6cec04 nt!KiFastCallEntry+0xf8
0b6cec34 00000000 00000000 00000000 00000000 0x7c90eb94


STACK_COMMAND: kb

FOLLOWUP_IP:
aswMon2+4d6a
eb267d6a ?? ???

SYMBOL_STACK_INDEX: 7

SYMBOL_NAME: aswMon2+4d6a

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: aswMon2

IMAGE_NAME: aswMon2.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 482c3a50

FAILURE_BUCKET_ID: 0xA_aswMon2+4d6a

BUCKET_ID: 0xA_aswMon2+4d6a

Followup: MachineOwner
---------

So I assume the issue is aswMon2.SYS

Am I right?

However, if I analyse the full dump I get



Microsoft (R) Windows Debugger Version 6.9.0003.113 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [D:\Memory Dumps\Athlon\20080605_MEMORY.DMP]
Kernel Complete Dump File: Full address space is available

Symbol search path is: D:\Debug_Symbols;SRV*D:\Debug_Symbols*Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_gdr.070227-2254
Kernel base = 0xe0b9b000 PsLoadedModuleList = 0xe0c1e620
Debug session time: Thu Jun 5 16:57:52.580 2008 (GMT+1)
System Uptime: 6 days 18:04:23.790
Loading Kernel Symbols
........................................................................................................................................................
Loading User Symbols
.................................................................................................................................................................................................................
Loading unloaded module list
..................................................................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {8b661e05, ff, 0, e0bb65a4}

*** ERROR: Module load completed but symbols could not be loaded for aswMon2.SYS
*** WARNING: Unable to verify checksum for PDFShell.dll
*** ERROR: Symbol file could not be found. Defaulted to export symbols for PDFShell.dll -
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of mscorwks.dll is
in the version directory
3) or, if you are debugging a dump file, verify that the file
mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
4) you are debugging on the same architecture as the dump file.
For example, an IA64 dump file must be debugged on an IA64
machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of mscorwks.dll is
in the version directory
3) or, if you are debugging a dump file, verify that the file
mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
4) you are debugging on the same architecture as the dump file.
For example, an IA64 dump file must be debugged on an IA64
machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************
Probably caused by : aswMon2.SYS ( aswMon2+4d6a )

Followup: MachineOwner
---------

kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 8b661e05, memory referenced
Arg2: 000000ff, IRQL
Arg3: 00000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: e0bb65a4, address which referenced memory

Debugging Details:
------------------

Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of mscorwks.dll is
in the version directory
3) or, if you are debugging a dump file, verify that the file
mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
4) you are debugging on the same architecture as the dump file.
For example, an IA64 dump file must be debugged on an IA64
machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of mscorwks.dll is
in the version directory
3) or, if you are debugging a dump file, verify that the file
mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
4) you are debugging on the same architecture as the dump file.
For example, an IA64 dump file must be debugged on an IA64
machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************

READ_ADDRESS: 8b661e05

CURRENT_IRQL: ff

FAULTING_IP:
nt!ExpFindCurrentThread+68
e0bb65a4 8b4104 mov eax,dword ptr [ecx+4]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: explorer.exe

MANAGED_STACK: !dumpstack -EE
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of mscorwks.dll is
in the version directory
3) or, if you are debugging a dump file, verify that the file
mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
4) you are debugging on the same architecture as the dump file.
For example, an IA64 dump file must be debugged on an IA64
machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.

TRAP_FRAME: ecc792e4 -- (.trap 0xffffffffecc792e4)
ErrCode = 00000000
eax=e0c3c101 ebx=00000000 ecx=8b661e01 edx=00000000 esi=e0c3c0e1 edi=f7f4fda8
eip=e0bb65a4 esp=ecc79358 ebp=ecc79370 iopl=0 nv up di ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010082
nt!ExpFindCurrentThread+0x68:
e0bb65a4 8b4104 mov eax,dword ptr [ecx+4] ds:0023:8b661e05=????????
Resetting default scope

LAST_CONTROL_TRANSFER: from e0bb65a4 to e0ba587f

STACK_TEXT:
ecc792e4 e0bb65a4 badb0d00 00000000 00000000 nt!KiTrap0E+0x233
ecc79370 e0ba840f ecc79397 00000020 ecc793d4 nt!ExpFindCurrentThread+0x68
ecc79388 e0c31110 e0c3c0e1 ecc793b4 00000002 nt!ExAcquireResourceSharedLite+0x43
ecc793b8 e0bbf309 ecc793d4 00000001 ecc79848 nt!NtQueryInformationToken+0xed2
ecc793c8 e0bbefd6 ecc79444 ecc79410 00000001 nt!mbtowc+0x33
ecc79848 e0bb6a44 ecc79860 eb267b88 ecc79890 nt!_woutput+0x44b
ecc79880 eb267d6a e57e5718 eb267b88 00000043 nt!swprintf+0x30
WARNING: Stack unwind information not available. Following frames may be wrong.
ecc798b4 eb269200 f9452908 f89bbd50 f95537b8 aswMon2+0x4d6a
ecc799d0 eb2699a4 f89dceb8 f89dcc98 ecc79a07 aswMon2+0x6200
ecc79a08 eb26383c f9553700 009dcc98 e0ba77f7 aswMon2+0x69a4
ecc79b04 e0c34c14 f9553700 00000000 f89b1a78 aswMon2+0x83c
ecc79b3c e0c2b6b5 f9452908 00000000 f89b1a78 nt!IopParseFile+0x46
ecc79bc4 e0c2b49a 00004140 ecc79c04 00000040 nt!ObpLookupObjectName+0x119
ecc79c18 e0c33a23 00000000 00000000 c79cb001 nt!ObOpenObjectByName+0xeb
ecc79c94 e0c33af2 0b6cec40 00120089 0b6cec04 nt!IopCreateFile+0x407
ecc79cf0 e0c33c28 0b6cec40 00120089 0b6cec04 nt!IoCreateFile+0x8e
ecc79d30 e0ba27ec 0b6cec40 00120089 0b6cec04 nt!NtCreateFile+0x30
ecc79d30 7c90eb94 0b6cec40 00120089 0b6cec04 nt!KiFastCallEntry+0xf8
0b6cebc8 7c90d68e 7753e8ad 0b6cec40 00120089 ntdll!KiFastSystemCallRet
0b6cebcc 7753e8ad 0b6cec40 00120089 0b6cec04 ntdll!NtCreateFile+0xc
0b6cec34 7753abc3 0b6cec58 00000000 00000020 ole32!CNtfsStorage::OpenNtFileHandle+0x84
0b6cec60 7753ab5d 0b6cec94 00000020 00000000 ole32!CNtfsStorage::OpenNtStream+0x33
0b6cee9c 7753aaa1 0b6ceec4 0b6cef78 00000010 ole32!CNtfsStorage::GetStreamHandle+0xcb
0b6ceec8 7753aa26 0b6cef78 00000010 00000000 ole32!CNtfsStorage::NewCNtfsStream+0x5a
0b6ceeec 7753aeda 075049a0 0b6cef78 00000000 ole32!CNtfsStorage::OpenStream+0x56
0b6cefc8 7753ae65 0b6cf06c 00000000 00000010 ole32!CNtfsStorageForPropSetStg::CreateOrOpenStorage+0x6b
0b6cefe8 7753ad71 075049f4 0b6cf06c 00000000 ole32!CNtfsStorageForPropSetStg::OpenStorage+0x4b
0b6cf0b0 7ca37940 075049ac 7ca36138 00000010 ole32!CPropertySetStorage::Open+0xfc
0b6cf0e8 7ca37ac1 00000000 7ca36138 00000006 SHELL32!ReadProperty+0x25
0b6cf120 7ca51a4e 024094f0 0c2001b0 00000017 SHELL32!CPropStgColumns::GetItemData+0x276
0b6cf37c 7cb30fae 0bf23d18 0bf28720 0b6cf3d0 SHELL32!CFSFolder::GetDetailsEx+0x44f
0b6cfde8 7cb310f2 0b6cfe20 0b6cfe68 7cb2a73b SHELL32!CInfoTip::_GetInfoTipFromItem+0x169
0b6cfdf4 7cb2a73b 0bf84ab0 00000000 0b6cfe20 SHELL32!CInfoTip::GetInfoTip+0x1c
0b6cfe68 7c9f2275 02408f08 0bffe928 0724da60 SHELL32!CStatusBarAndInfoTipTask::RunInitRT+0xf5
0b6cfe84 75f81b9a 02408f08 75f81b18 75f80000 SHELL32!CRunnableTask::Run+0x54
0b6cfee0 77f69498 02332d68 00181b68 77f6947b BROWSEUI!CShellTaskScheduler_ThreadProc+0x111
0b6cfef8 7c927545 00181b68 7c97c3a0 00182300 SHLWAPI!ExecuteWorkItem+0x1d
0b6cff40 7c927583 77f6947b 00181b68 00000000 ntdll!RtlpWorkerCallout+0x70
0b6cff60 7c927645 00000000 00181b68 00182300 ntdll!RtlpExecuteWorkerRequest+0x1a
0b6cff74 7c92761c 7c927569 00000000 00181b68 ntdll!RtlpApcCallout+0x11
0b6cffb4 7c80b683 00000000 036ef248 036ef248 ntdll!RtlpWorkerThread+0x87
0b6cffec 00000000 7c910760 00000000 00000000 kernel32!BaseThreadStart+0x37


STACK_COMMAND: kb

FOLLOWUP_IP:
aswMon2+4d6a
eb267d6a 83c40c add esp,0Ch

SYMBOL_STACK_INDEX: 7

SYMBOL_NAME: aswMon2+4d6a

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: aswMon2

IMAGE_NAME: aswMon2.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 482c3a50

FAILURE_BUCKET_ID: 0xA_aswMon2+4d6a

BUCKET_ID: 0xA_aswMon2+4d6a

Followup: MachineOwner
---------

Windows path is
PATH=C:\Program Files\PC Connectivity Solution\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\PROGRA~1\COMMON~1\ULEADS~1\MPEG;C:\PROGRA~1\RESOUR~1;C:\Program Files\Symantec\pcAnywhere\;C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\;C:\Program Files\Debugging Tools for Windows;

Symbol path is
D:\Debug_Symbols;SRV*D:\Debug_Symbols*
What is all this this about?

If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************


MANAGED_STACK: !dumpstack -EE
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of mscorwks.dll is
in the version directory
3) or, if you are debugging a dump file, verify that the file
mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
4) you are debugging on the same architecture as the dump file.
For example, an IA64 dump file must be debugged on an IA64
machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

Why can't it find the symbols and all the info it needs?

Any ideas anyone?

Sorry once again for the humungeous post.
 
uninstall Avast and install the latest version
do not run Symantec or Norton at the same time you are running Avast

just my suggestion
 
That file (mscorwks.dll) on the machine I checked seems to be tied up with.Net Framework.



This mentions the Environment Variables in passing.
Windows Debugger, part of Never-Ending-Problem
thread779-1064535

See if you can get any information from Google.



Debugging a DUMP file in XP
thread779-1292544
 

eyec (TechnicalUser) 5 Jun 08 18:52

uninstall Avast and install the latest version
do not run Symantec or Norton at the same time you are running Avast

just my suggestion

I have the latest version of Avast and I don't have any other anti-virus software.

Thanks for your efforts - unfortuantely not in themselves very helpful. However, you did lead me to this page


From which I conclude that the problem is in windbg.

I'm sending the minidump to Avast.

I have a couple of related questions though, if I may.

I have configured this machine to make a full dump and NOT to re-boot. On this occasion though it made a full and a minidump. Is that normal, to make both kinds of dump? In addition it did re-boot automatically! Rather than staying on the blue screen. Why?
 
After you chose your settings, maybe there has to be a reboot (or logoff, login) for the settings to become cemented into the Registry?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top