1

I need to read information, code, flags, address, etc from a memory.dmp file generated from a windows BSOD through C++. The basic idea is that status info can be requested from a remote site and one of the requested pieces of information is some basic info from the last BSOD that occured on the machine thus I need to open the kernel/memory dump file through C++ (Im using MSVC 2005).

Kevin L
  • 55
  • 1
  • 10
  • 3
    Why not script Windbg or if all fails write a Windbg extension? – Alois Kraus Nov 10 '14 at 15:26
  • Windbg is not installed on the machines I need to pull the info from and I am not allowed to install any executables to them. – Kevin L Nov 10 '14 at 15:42
  • Well how do you execute C++ code on the machines? You know that you can load the memory dump via an UNC share path from remote machines? – Alois Kraus Nov 10 '14 at 15:44
  • I am working on an existing dll which will eventually be pushed to the machines during an upgrade cycle that is out of my hands. Thus anything I do has to be self contained within the dll. All of the machines are at remote sites and most connect via either cellular or satellite networks. It was requested that I just add a small bit of information to an existing status message that the machines already return to the host. – Kevin L Nov 10 '14 at 15:49
  • 1
    I doubt you will find anyting from a kernel dump without using a debugger. You could reconfigure WER (Windows Error Reporting) and collect the kernel mini dumps which are normally sent to MS. These are very small. – Alois Kraus Nov 10 '14 at 15:52
  • @AloisKraus I agree that's the best solution, but I'd guess the target systems are configured not to send these if they're as locked down and unreachable as they sound. – Rup Nov 10 '14 at 15:57
  • 1
    Yes I meant that you can configure WER to store the minidumps locally so you can transfer them on your own via your dll to your HQ. Otherwise you will have a hard time to walk through kernel structures in C++ without any help from a debugger. – Alois Kraus Nov 10 '14 at 16:31
  • I also have to deal with the cost of bandwidth so just about any message over about 20 bytes is zipped to save on bandwidth so transferring a minidump would make the accountants scream. – Kevin L Nov 10 '14 at 16:42

2 Answers2

1

Start here, then realize using scripted commands in WinDBG is much easier.

Note: you only need WinDBG on the analysis machine, not the crashing one. You retrieve the minidump and analyse it externally. The only difficulty you will have is getting the right symbols - for Windows, Microsoft makes them available via their symbol servers, but applications that caused the crash may not supply the right symbols you need. IF they are you own applications causing the crash, get a symbol server and use it.

gbjbaanb
  • 51,617
  • 12
  • 104
  • 148
  • I am already using MiniDumpReadDumpStream to read Dr Watson generated files but it is not reading the MEMORY.DMP file that was generated by a BSOD. I also cannot access the dump file remotely due to the network architecture and the high cost of bandwidth. – Kevin L Nov 10 '14 at 15:54
  • That's interesting - I thought BSOD dumps were minidumps. Maybe this only applies on newer versions of Windows. You can script ntsd but that will come to around 5mb to copy to the clients. Or you could look at [Breakpad](https://code.google.com/p/google-breakpad/wiki/GettingStartedWithBreakpad) – gbjbaanb Nov 10 '14 at 16:00
  • They actually might be. I am testing using a BSOD dump file generated by a call to KeBugCheckEx which only takes 5 parameters and the status info Im sending back isnt contained within those 5 paramters so maybe the streams I need to read arent being generated thus that would be why MiniDumpReadDumpStream is returning FALSE. do you have any idea what stream would contain Bug Check and the 4 parameters? – Kevin L Nov 10 '14 at 16:15
  • Alas no, I only use windbg or VS for post-mortem debugging. – gbjbaanb Nov 10 '14 at 16:38
  • This thread [link](http://stackoverflow.com/questions/10589587/windbg-is-it-possible-to-embed-windgb-engine-in-my-own-program) makes it sound like MiniDumpReadDumpStream should work with kernel-mode dump files so I need to get my hands on a full BSOD dump file from one of the machines that I need to work with. – Kevin L Nov 10 '14 at 17:31
0

I would configure Windows to create small kernel memory dumps which will include the parameter of the bugcheck you are after.

On XP it was 64KB on my Win8.1 x64 it is 256KB. These files compress well. You should be able to get away with a zip file of 10-60KB size depending on the bitness of the OS. If bandwidth is of of utmost importance to you, you can use 7z which compresses about 50% better than the plain zip algo at the expense of much longer compression times (5-6 longer) but for such small files the CPU time difference should be irrelevant.

If you do not want your users to configure dump reporting you need to set the DWORD

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

to 3 for a small kernel dump programatically.

For an explanation of the values see http://technet.microsoft.com/en-us/library/cc976050.aspx

  • 0 Debugging information is not written to a file.
  • 1 Complete crash dump is written to a file.
  • 2 Kernel memory dump is written to a file.
  • 3 Small memory dump is written to a file.

You will then get by default a small kernel dump in %SystemRoot%\MEMORY.DMP.

Alois Kraus
  • 13,229
  • 1
  • 38
  • 64
  • Well I found out late yesterday that the machines in question dont even have the Windows Error Reporting service installed thus Im not going to be able to gather any info from looking at dumps since none will be made. – Kevin L Nov 11 '14 at 16:33
  • Kernel dumping is not an optional feature. It is always there. – Alois Kraus Nov 11 '14 at 18:36
  • The guys who built the base drive didnt install the Windows Error Reporting service. This is Windows 7 Embedded. – Kevin L Nov 11 '14 at 20:48
  • Kernel Dumps have not much to do with WER. As I said it is always there. It could be that the UI is missing but the registry keys will work. – Alois Kraus Nov 11 '14 at 22:21
  • Well the machine I have to test with isnt making dump files event though it is set to, has a valid location for saving them, tried setting paging file to both 2GB and system managed. The only thing I could find is that the WER service is missing. – Kevin L Nov 13 '14 at 13:48
  • What is your valid location? Try leaving the default (no location set). Perhaps the other volume is not mounted at this point to which you want to write to. – Alois Kraus Nov 13 '14 at 14:04
  • Its set for a small memory dump to %SystemRoot%\Minidump – Kevin L Nov 13 '14 at 17:06
  • How do you test the blue screen? With the CrashOnCtrlScroll setting? That forces a crash dump. Try setting it to a full dump and see how long it takes. If no dump is written it should restart very fast. If not the data is somewhere else written. – Alois Kraus Nov 13 '14 at 19:58
  • I was using the StartBlueScreen utility. CrashOnCtrlScroll didnt work on that machine. I cant change the dump settings due to not having access to the machines in the field. – Kevin L Nov 13 '14 at 20:12
  • The simpliest would be to check for *.dmp and search on the C drive for them. Besides this I have somewhere read that minidumps were stored in %systemroot%\MiniDumps but that was an XP site which is perhaps not applicable here. – Alois Kraus Nov 13 '14 at 21:06
  • I have done that and they arent being stored anywhere on the disk. – Kevin L Nov 14 '14 at 15:03
  • Hm did you disable the page file? You need a page file at least as big as your physical memory to be able to take a full memory dump. Or has your machine less than 25 GB of free HDD space? http://blogs.msdn.com/b/wer/archive/2009/02/09/kernel-dump-storage-and-clean-up-behavior-in-windows-7.aspx. In that case you should be able to see in the System Event Log messages indicating what was going on. Perhaps it was deleted due to not enough HDD space. – Alois Kraus Nov 14 '14 at 17:34
  • page file is 2GB, only 512MB of memory in the machine. It only has bout 11GB of free space on disk. Event log doesnt show anything relating to the BSOD. – Kevin L Nov 14 '14 at 19:58
  • In that case you need to drill deeper. Perhaps a support call at MS will help here. With no dump you have nothing to analyze. – Alois Kraus Nov 14 '14 at 21:43