windbg

I'm having an annoying issue with Pykd.pyd : I'm using it in a script, launching several DbgCommand functions, like: DbgCommand("dt 0x000000eab8748430 CMap<int,int,CUIntArray *,CUIntArray *> m_nCount") This for getting the size of the CMap object. As this is done in a script, using lots and lots of objects, I am using logfiles in Windbg (menu edit , Open/Close Log File ), and here's the catch: When looking at this in Windbg window, I only see the results of the DbgCommand calls, but in the logfile I see the command itself too: Windbg window: 000000eab87488f0 CMap<int,int,CUIntArray *

I have a crash dump from my app showing a bunch of threads waiting on a syncblk, and the syncblk shows that it has no owning thread. How is that possible? I'm trying to reproduce the symptom in a test app, and I can't figure out what could possibly happen to produce that result....having the owning thread exit or die without releasing the syncblk still shows up as owning the object, just the threadid is "XXX"....I've tested using fully managed graceful exit and hard thread termination via pinvoke....I tested a bunch of different combinations of waits without pulses, mismatched enters and exits

I have a crash dump and I suspect GDI leaks to be a cause of the crash From the full crash dump is there anyway to find out the number of GDI handles used by my process when it crashed? It is unlikely since the only debugger extension gdikdx.dll tailored at gdi tasks is not actively maintained since the w2k version and i believe they stopped shipping it since not that many folks are into hacking into gdi internals - according to someone's statement i stumbled upon in a newsgroup - therefore it is no longer invested into. You're left with only a few options all of which are unfortunately about

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

Any way to make Windbg to break when a specific value is assigned to the eax register? I know one of the functions in my program is returning an specific error, it would be very fast to find the guilty this way. You can set a breakpoint on all your suspect functions and then check the eax register value like so: bp myAddress ".if (@retreg == dodgyVal) {walk the stack and do other cool stuff} .else {gc}" See conditional breakpoints and also pseudo-register syntax for available register values 来源： https://stackoverflow.com/questions/16973882/break-when-a-register-has-an-specific-value

I'm trying to analyze some mini crash dumps. I'm using Windows 10 Pro Build 1607 and WinDbg 10.0.14321.1024. I have my symbol file path set to SRV*C:\SymCache*https://msdl.microsoft.com/download/symbols Basically, whenever I load up a minidump (all < 1 MB .dmp files), it takes WinDbg forever to actually analyze them. I understand the first run can take long, but it took mine almost 12 hours before it would let me enter a command. I assumed that, since the symbols were cached, it wouldn't take long at all to re-open the same .dmp. This is not the case. It loads up, goes pretty much

I'm doing some crash dump debugging, where I am looking a dump taken from a production server. The machine I'm running WinDbg on must have a slightly different version of the .NET runtime installed -- I'm getting errors loading the native images of .NET system assemblies (so can't load for example System.Data.Linq ). What is the best way to ensure that my debug machine has access to all the right symbols? Edit Added output of lmv for Thomas Weller 000007fb`68660000 000007fb`68993000 System_Data_Linq_ni C (pdb symbols) C:\Program Files\Debugging Tools for Windows (x64)\sym\System.Data.Linq.pdb