windbg

问题 I'd like to create a breakpoint such that it will create another one-time breakpoint that will 'dd' a certain memory address when that memory is written to. So when the breakpoint is hit, I'd like to run a command like: ba w4 @ESP+4 /1 ''dd [memory address of this breakpoint]'' Since this breakpoint is being created by another breakpoint (and could potentially be called several times), I can't specify the breakpoint number. Otherwise I could use a pseudo register like '$bp3' to get the memory

问题 I want to put a conditional breakpoint in windbg. For example lets say LoadLibrary API. How can I put breakpoint such that it should it whenever user32.dll get loaded. > x kernel32!LoadLibraryW It will give some address [XXXX] Now I can put breakpoint as > bu [XXXX] but this will hit for all calls to LoadLibraryW. Any suggestions. 回答1: you can not set a conditional breakpoint on a user32.dll since it's being mapped into the address space relatively early and the initial debugger's breakpoint

问题 The long (boring) story Currently i have an application that leads to an exception on only one pc. After some digging around i could encapsulate the problem with a small sample application, but the true reason is still hiding. Due to the fact that on this pc is no Visual Studio installed nor we are able to do so i searched for another solution to find the true reason. In a first approach i stripped down my small application more and more by just carefully reading the exception message,

问题 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

问题 How can I calculate heap chunk size from raw bytes read from memory. I tried below thing. 0:001> !heap Index Address Name Debugging options enabled 1: 00500000 2: 00280000 3: 008f0000 4: 00ab0000 5: 00cc0000 0:001> !heap -a 00500000 .. .. Heap entries for Segment00 in Heap 00500000 address: psize . size flags state (requested size) 00500000: 00000 . 00588 [101] - busy (587) 00500588: 00588 . 00240 [101] - busy (23f) 005007c8: 00240 . 00020 [101] - busy (18) 005007e8: 00020 . 00ca0 [101] -

问题 How can I calculate heap chunk size from raw bytes read from memory. I tried below thing. 0:001> !heap Index Address Name Debugging options enabled 1: 00500000 2: 00280000 3: 008f0000 4: 00ab0000 5: 00cc0000 0:001> !heap -a 00500000 .. .. Heap entries for Segment00 in Heap 00500000 address: psize . size flags state (requested size) 00500000: 00000 . 00588 [101] - busy (587) 00500588: 00588 . 00240 [101] - busy (23f) 005007c8: 00240 . 00020 [101] - busy (18) 005007e8: 00020 . 00ca0 [101] -

问题 I have a dump which has both .NET versions loaded: 0:000> lm m clr start end module name 65490000 65aff000 clr (deferred) 0:000> lm m mscorwks start end module name 6a980000 6af2c000 mscorwks (deferred) Now I'm uncertain which version of SOS to use. Both will load without problems. 0:000> .loadby sos mscorwks 0:000> .loadby sos clr How would I find out which version to use best for my analysis? Or will I always need both? Is .cordll -ve -u -l reliable in this case? .symfix c:\symbols .cordll

问题 I am using WinDbg to look into a process dump. The dump has been taken on an x86 server with .NET 4 SP1 (4.0.30319.237). I'm attempting to debug on my x64 machine using the x86 version of WinDbg, but I get the following issue. 0:000> !EEVersion The version of SOS does not match the version of CLR you are debugging. Please load the matching version of SOS for the version of CLR you are debugging. CLR Version: 4.0.30319.237 SOS Version: 4.0.30319.239 4.0.30319.237 retail Workstation mode SOS

问题 I'm looking into why a managed process is using a lot of memory. Is there a way to run GC.Collect(3) from WinDbg, so that I can focus on the actual memory allocation? 回答1: I don't think there is any way to run a .NET garbage collection from WinDbg, but I also don't think it is necessary. See Rico Mariani's Performance Tidbits - Tracking down managed memory leaks (how to find a GC leak) for information about finding out what kind of stuff is on your heap. Additional possibly useful links: When

问题 I'm trying to get used to working with WinDbg to troubleshoot crash dumps when I'm able to get them, but every time I do it seems it's asking me for a different version of mscorwks.dll and mscordacwks.dll, and I don't always have access to the machine the dump came from. Other than telling end users they have to dig around in their Windows directory for these files on top of sending me an absurdly large "mini"-dump, is there somewhere I can get copies of different builds of these files?