sos

I'm trying to track down a NullReferenceException from a dump. The NullReferenceException is not the crashing exception, rather the crashing exception is a TargetInvocationException with an InnerException which is the NullReferenceException. I'm using Windbg with SOS, I use the the command analyze -v and this gives me the call stack of the NullReferenceException: EXCEPTION_OBJECT: !pe f6cb150 Exception object: 000000000f6cb150 Exception type: System.NullReferenceException Message: Object reference not set to an instance of an object. InnerException: <none> StackTrace (generated): SP IP

I've started to read some materials on advanced debugging tools and techniques. I use VS2012 Ultimate and the target framework is .NET 4.0. I got to the point where I need to load SOS.dll in the Immediate window during a debug session and it just doesn't work. I tried these with no luck .load sos .load sos.dll .load C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll I always get this message: Invalid expression term '.' So, any idea ? What am I missing here ? You can change this setting to work around the issue: Under Tools->Option->Debugging->General, check the box labeled "Managed

My problem is this: 0:000> !DumpHeap -type Microsoft.Internal.ReadLock -stat ------------------------------ Heap 0 total 0 objects ------------------------------ Heap 1 total 0 objects ------------------------------ Heap 2 total 0 objects ------------------------------ Heap 3 total 0 objects ------------------------------ total 0 objects Statistics: MT Count TotalSize Class Name 000007fef3d14088 74247 2375904 Microsoft.Internal.ReadLock Total 74247 objects The way I read this output is that I have 74,247 Microsoft.Internal.ReadLock instances on my heap. However, some of them are probably

For some reason, I cannot run any commands once I load psscor4. I have downloaded x64 of psscor4 from MS website and put it in same folder where windbg is. Before loading psscor4, I can run sos commands fine without any problem. 0:003> .loadby sos clr 0:003> lmvm clr start end module name 00007ffa`35630000 00007ffa`35fc8000 clr (deferred) Image path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll Image name: clr.dll Timestamp: Wed Nov 27 19:25:30 2013 (52968D7A) CheckSum: 00996ED8 ImageSize: 00998000 File version: 4.0.30319.34011 Product version: 4.0.30319.34011 File flags: 8 (Mask 3F

How do I dump a struct using windbg, is there a dumpstruct command similar to dumpobject? Or can dumpobject dump structs aswell? Yes, you could use the !dumpvc command. Since structs don't have an object header, the debugger doesn't know its type, so you will have to pass it the struct's MethodTable address. >!DumpVC <METHOD_TABLE_ADDRESS> <OBJECT_ADDRESS> 来源： https://stackoverflow.com/questions/3717292/windbg-with-sos-how-to-dump-a-c-sharp-struct

We are trying to analyze a w3wp memory dump using windbg and we found that w3wp process is crashing due to stack overflow. I loaded the psscor4.dll and got the call stack by issuing !clrstack. But I also want to know the paramaters being passed to the methods. If I issue "!clrstack -p" or "!clrstack -a", we are getting <no data> for all the Parameters and local variables. Any idea, why we are getting <no data> instead of actual values for the Parameters and local variables ? If you're running a release build you will usually not be able to track locals and parameters as they are optimized and

The Question There are plenty of manual ways to make WinDBG find mscordacwks.dll without a symbol store (putting the file in the path somewhere, putting it in the same folder as windbg.exe, putting it in my Framework\v folder, specifying the path in WinDBG using .cordll -lp c:\dacFolder , etc.), but they all only fix it for me . I need to fix it more generally for everyone who uses my symbol store . The possible solutions I can imagine are: WinDBG be made to check the symbol store using mscordacwks.dll's subfolder name instead of mscorwks.dll's folder name. SymStore.exe be made to add

The documentation said it's used for limit the size of the output object, but based on my test, it's not what I expected: 0:000> !dumpheap -mt 000007fee12406a8 -max 400 -min 399 Address MT Size 000000000d1dc1f8 000007fee12406a8 936 000000000d62bed8 000007fee12406a8 1016 000000000d630d00 000007fee12406a8 984 000000000d633aa8 000007fee12406a8 984 000000000d65f368 000007fee12406a8 952 000000000d685ff0 000007fee12406a8 952 000000000d6b2150 000007fee12406a8 952 So how to understand the -min and -max options? WinDbg's default number format is hexadecimal. 0x400 is 1024 and 0x399 is 921, that