Recently I was asked to investigate quite an interesting case. I had a dump file that Windows created, I started WinDbg and opened that dump file and I saw this:

(7b9c.ab4): Access violation - code c0000005 (first/second chance not available)
For analysis of this file, run !analyze -v
MyProgram!MyModule.SomeClick+0x71:
00000014`00ace011 5b              pop     rbx

Usually, an Access violation happened when there is an attempt to read or write from memory.  But in this, quite a rare case application crashes on pop instruction. But as everybody knows pop and push instructions do read from and write to memory because the stack is located in the same memory as everything else. So my next

Case of frozen File Explorer

Some time ago I started to get strange freezes when I try to open File Explorer. New File Explorer appears on screen, renders left and top part and then displays “Working on it…” where files supposed to be and then nothing. And today I would like to share my discoveries.

Obviously, first thing I tried to kill File Explorer and start over. Exactly the same behavior. I rarely use File Explorer because I prefer FAR file manager. But sometimes I do use File Explorer, mostly to copy files via Remote Desktop. In this particular case I decided to start FAR file manager to check something. And to my surprise, exactly the same happens to FAR.

I was asked to investigate why one of our web services constantly consuming more than 3Gb of memory and constantly recycled. There was nothing new deployed at that time and developers do not understand what’s going on.

After I got memory dump, that contains .NET code I execute this command first:
.cordll -ve -u -l

Then for memory related issues I usually execute this command:
!DumpHeap -stat

This will print how many instances of each object created and total size in memory these objects are consuming. Then I try to find some specific objects at the bottom of this list. General objects like strings usually hard to investigate as many objects has a lot

My previous post explained that for 32-bit process, 32-bit tool should be used, or most tools got confused. Visual Studio able to handle standard PDB files but got confused on PDB files that was custom generated. Normally I would recommend using 32-bit tool and forget about this problem. But in some cases, crash could be so rare, that it worth investigating how to get anything useful from such “bad” dump. And I will show, how to do it.

Firstly, load 32-bit WinDbg and execute following commands:
.load wow64exts.dll
!sw
!r

This will load standard wow64exts WinDbg extension, switch to 32-bit mode, even dump is 64 bit and displays 32-bit context record. From context record