Failed to start stack walk: 80004005, Following frames may be wrong and other errors you may see in windbg

When you debug .net applications you will sometimes get error messages in windbg. Here are a few of the ones I most commonly get questions around…

Failed to start stack walk

If you run the sos command !clrstack to display the .net stack on a thread, and this thread is a .net thread but it is not currently running any .net code, sos will spit out Failed to start stack walk: 80004005. This does not mean that there is anything wrong with the process or with the debugger. It simply means that sos can’t display the stack because there is none.

OS Thread Id: 0x1ec (12)
Failed to start stack walk: 80004005

Unable to walk the managed stack

If you run !clrstack on a native thread (i.e. a thread that has no corresponding System.Threading.Thread), sos will display the following message instead.

OS Thread Id: 0x554 (11)
Unable to walk the managed stack. The current thread is likely not a
managed thread. You can run !threads to get a list of managed threads in
the process

Following frames may be wrong

If windbg can’t resolve a symbol it will give an ERROR the first time it encounters this symbol telling you that the symbol file could not be found, and all subsequent times it encounters this symbols it will give you a WARNING, telling you that it can’t unwind the stack properly. When you see this message it means that anything you see below the WARNING note may be incorrect so you can’t trust the stack from there on. In this case for example we can see that the stack is waiting to enter a critical section, and that some method in DataLayer.dll is trying to enter a critical section, however because we don’t have proper symbols for DataLayer.dll we can not say if it is the method DllUnregisterServer or not. In fact most likely DllUnregisterServer is just the last exported symbol name, otherwise we would be at an offset of 0x43fb which means that this method would be very very long.

Not only do we not know if this is the right method name or not, but windbg may even loose stack frames when it doesn’t have the proper symbols so you really shouldn’t trust this stack at all.

For a discussion on symbols, how they work etc. see this post

0:018> kL
ChildEBP RetAddr
020eea58 77f8f295 NTDLL!NtWaitForSingleObject+0xb
020eeacc 77f87f26 NTDLL!RtlpWaitForCriticalSection+0x9e
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for DataLayer.dll -
020eead4 6010f8b2 NTDLL!RtlEnterCriticalSection+0x46
WARNING: Stack unwind information not available. Following frames may be wrong.
020eeae4 6012e72b DataLayer!DllUnregisterServer+0x43fb
...

Failed to load data access DLL, 0x80004005

This error means that

• you are loading the wrong version of sos.dll, i.e. in this case I loaded the 2.0 version in a 1.1 dump, or
• it can’t find the proper version of mscordacwks.dll.

If it is the second option, try turning on !sym noisy and run .cordll -ve -u -l. And of course, as the error message mentions, make sure that you have a full dump rather than a mini dump.

0:167> !clrstack
Doesn't work with 1.x
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
            1) the file mscordacwks.dll that matches your version of mscorwks.dll is
                in the version directory
            2) or, if you are debugging a dump file, verify that the file
                mscordacwks___.dll is on your symbol path.
            3) 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.

Laters, Tess