Partager via

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

  • Article

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 <br>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 a) 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 b) it can't find the proper version of mscordacwks.dll.  If it is option b, 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.  Check out this post for some basics on memory dumps.

 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)
            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___.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.

 

Laters,

Tess

Comments

  • Anonymous
    May 13, 2008
    Thanks, that was helpful information....

  • Anonymous
    May 23, 2008
    Dear Tess, Please could you reduce the width of lines in your posts? It is difficult to skim your posts in RSSBandit because of that short horizontal bar taking a mile or so :( I cannot simply roll my mouse down to skim. http://blogs.msdn.com/tess/rss.xml is too wide to fit in the normal outlook standard-width reading pane. Cheers.

  • Anonymous
    May 23, 2008
    I will do my best... is it the debug output or everything?  Does the text not wrap?

  • Anonymous
    May 25, 2008
    everything. the text too doesn't wrap.

  • Anonymous
    May 25, 2008
    Hi Narasimha, I just downloaded RSS Bandit and subscribed to my feed. In my copy of RSS bandit it seems to be word wrapping properly.  I have resized the viewer and the word wrap seems to follow, so I am not sure what the difference is there.  I tried it on 3 different machines here and got the same results.  Are you just seeing this issue with my feed?   I have compared HTML with other blogs and they don't seem to put extra <br/> at the end of lines which is what i would have to do to manually word wrap.  I would prefer not to do so as it will make things look weird in other readers.

  • Anonymous
    May 26, 2008
    Tess, In RSS bandit, I've configured it to show list of your posts on top and view on bottom. I hope you have similar way. If I see individual post of yours it is ok. What I'm talking about is seeing list of posts' view. Click on the link in "My Feeds" on the left pane. Right side top view shows list of all your posts. Bottom view shows these posts which I can scroll down one by one. In this view is what I face this problem. Btw, other authors on MSDN seems ok. Though some of them have horz. bar. For best result benchmark see Vista Team blog: http://windowsvistablog.com/blogs/default.aspx Their posts appear nicely wrapped.

  • Anonymous
    May 26, 2008
    hey Tess, also see Roberto Farah's http://blogs.msdn.com/debuggingtoolbox/default.aspx they too appear without horz. bar. :) Btw, in this view RSSBandit only shows those posts which are still unread.

  • Anonymous
    May 26, 2008
    The comment has been removed

  • Anonymous
    May 26, 2008
    I had a look at home with some different feeds in RSSBandit and it looks like half of them have one behavior and half have the other behavior. When I view mine it doesnt word wrap if I resize the window to be smaller than the screen width, if i maximize it it works fine.  So it seems like some feeds just have a smaller width than others and I can't say why that is, but im guessing it has something to do with the theme used. Based on the feeds that have wordwrap even when resized I can say that the source reveals that they do not do anything special as far as breaking lines etc.  so I am not really sure what to do to make it show up properly in RSS bandit when resized.  I'm sorry:(

  • Anonymous
    May 26, 2008
    Hi Tess, taking your cue, I changed my xsl format to "kuro5hin" template for your posts and voila! your text fits. :) Thanks anyway. Cheers.

  • Anonymous
    May 26, 2008
    The comment has been removed

  • Anonymous
    May 27, 2008
    Tess, it is my due to give you a big thanks for this very useful blog. I learned a lot from here. Allow me to buy you cup of coffee, 'heap' of chips and a sandwich with few megabytes of free stack trace, thinly cut ham and topped with mayonnaise SOS.

  • Anonymous
    May 27, 2008
    :)  funny, thanks Narashima

  • Anonymous
    February 18, 2009
    Ever seen this error in a WinDBG/CDB debug session? Failed to load data access DLL, 0x80004005 Verify

  • Anonymous
    November 04, 2009
    Thanks Tess for all your posts. Failed to load data access DLL, 0x80004005 This can also happen in !VerifyHeap. My solution:

  1. unload SOS (.unload SOS), because wrong version is loaded
  2. load modules (ld *)
  3. load SOS (.loadby sos mscorwks), should load the correct version now
  4. !VerifyHeap

  • Anonymous
    February 18, 2010
    The comment has been removed

  • Anonymous
    February 18, 2010
    additional information:   But DumpStack -EE seems to work correctly.  It is CLRStack that doesn't work...  

  • Anonymous
    February 18, 2010
    Tooshkan, The problem you are facing there is that you are getting a dump of the WOW and sos won't work all that great with that.  The best is to get a dump with a 32-bit debugger in that case, so 32-bit debugging tools for windows for example and get a dump with adplus.

  • Anonymous
    February 18, 2010
    Tess, Thank you for your reply.  So it is not just about what tools to use to READ the dump, it is also about which tools to use to TAKE the dump?  Currently I am using WinDbg 32 bit to read the wow64 dump.  And what you are saying is I first need to to use a 32 bit tool to take the 32 dump of a wow process and then read it using WinDbg32 and that should work better? That way it would be a true 32 dump as if it was taken on a 32 bit machine with all that wow stuff completely out?

  • Anonymous
    February 21, 2010
    That is correct, you need to take it with the right debugger, otherwise you will get a dump of the wow

  • Anonymous
    August 31, 2010
    Hi Tess, In response to the last comment, what tool do you recommend to use for taking a dump of a 32-bit process on a 64-bit server to avoid the WOW?  We have some Citrix servers running Windows Server 2008 R2 x64 and I've been using Process Explorer to take the full user dump.  It seems to still have the WOW info in there. Thank you for your time : )

  • Anonymous
    February 15, 2011
    The comment has been removed

  • Anonymous
    February 15, 2011
    Well, not sure if procdmp from sysinternals will give you a 32-bit dump here, technically though you can debug the WOW dumps and just run !wow64exts.sw to switch to the 32bit context and that should give you most of what you want.

  • Anonymous
    May 27, 2012
    Great! helped a lot!