"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 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

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.




Comments (24)

  1. Thanks, that was helpful information….

  2. 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.


  3. Tess says:

    I will do my best… is it the debug output or everything?  Does the text not wrap?

  4. everything. the text too doesn’t wrap.

  5. Tess says:

    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.

  6. Narasimha Vedala says:


    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.

  7. narasimha vedala says:

    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.

  8. Narasimha Vedala says:

    I did some comparison with other authors: I think they explicitly enter a new line (rn) in the html code wrapped in <p></p>, while your text is one single long line inside <p></p>

  9. Tess says:

    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:(

  10. Narasimha Vedala says:

    Hi Tess,

    taking your cue, I changed my xsl format to "kuro5hin" template for your posts and voila! your text fits. 🙂

    Thanks anyway. Cheers.

  11. Tess says:

    awesome, thanks for the tip.  I’ll add that too to my RSS Bandit.

    I use on-line RSS readers because I want it to be portable so i can keep read/unread posts anywhere i go, but after seeing this reader I am almost thinking about converting.

  12. 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.

  13. Tess says:

    🙂  funny, thanks Narashima

  14. Ever seen this error in a WinDBG/CDB debug session? Failed to load data access DLL, 0x80004005 Verify

  15. Thomas says:

    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

  16. tooshkan says:

    I am getting a slightly different error when executing !clrstack:

    Failed to start stack walk: 80070057

    This is a 32 bit version of WinDbg running on a 64 bit 2008 box. The process dump is a dump of a 32 bit .NET application running on the same 2008 box. The dump was taken from the task manager.   SOS and mscordacwks were loaded correctly (x86 versions).  Then  I loaded wow64exts and switched to the x86 mode (!sw). !threads lists .NET threads correctly. But  ~*e!clrstack results in the error above.    And  .cordll -ve -u -l   always says "No load attempts"

    Any ideas?


  17. tooshkan says:

    additional information:  

    But DumpStack -EE seems to work correctly.  It is CLRStack that doesn’t work…  

  18. Tess says:


    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.

  19. tooshkan says:


    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?

  20. Tess says:

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

  21. Dave Black says:

    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 : )

  22. daveblack says:

    Hi Tess,

    In response to your 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.  I know that you can also use Task Manager and of course WinDbg.  However, running WinDbg on a PROD server is not an option for me.

  23. Tess says:

    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.

  24. dux says:

    Great! helped a lot!

Skip to main content