Problem with Windbg and native image executables

Question

I'm using windbg version 10.0.14321.1024 and I've noticed an issue with it's handling of native image (.ni.dll) executables.

If I use windbg to load a crash dump for a mixed (.Net and native) application that was generated on a different PC and try analyse the cause of the crash (!analyze -v), the UI seems to lock up.

On examining what is happening I have found that windbg is attempting to locate native image dlls by searching the symbol path. Since the crash was generated on another system these files won't be present on my system ad as I have access to a particularly large symbol hierarchy this means that the windbg process takes an extremely long time to search for the given native image dll, which it then fails to find. If there are several native image dlls to be located (which there inevitably are) then this just compounds the matter.

I don't really care whether or not the dll is loaded because most of the time I'm interested in a call stack that does not contain any native image dlls, so I guess I have several questions.

1. Why is windbg loading dlls that are not relevant to the current call stack?
2. Why is windbg searching the symbol store for the dlls - shouldn't it restrict the search to the default PATh and Image Path?
3. Why has the behaviour of windbg changed (because I'm pretty sure that older versions of windbg did not do this?
4. Is there any way to prevent windbg performing this wholesale scan of the symbol path for .ni.dll images (e.g. the exclusions list in symsrv.ini)?

Paul Mateer

Answer 1

This question is outside the scope of this site (for consumers) and to be sure you get the best answer it should be asked either on Technet (for IT Pro's) or MSDN (for developers)

http://social.technet.microsoft.com/Forums/en-us/home s/en-US/home

http://social.msdn.microsoft.com/Forum

---

If you give us a link to the new thread we can point some resources to it