0

I've designed a logging service for multiple applications in C#. Since the thinking of performance saving, all logs should be store in buffer first, and then write to log file when buffer is full. However, there are some of extension cards (PCI / PCI-e) causing BSoD, which are not in my control. The logs in the buffer will lose when the BSoD occurs, but I want to find a way to keep them.

I've found some articles are discussing about how to dumping data when software crashed. However, the minidump one needs to dump everything by myself, and I think it will cause some performance issues; the other articles (A)(B) are only suitable in single application crash.

Do anyone have any suggestion to save my logs even if BSoD occurs?

EDIT: if there are any suggestion to reduce the loss of data to minimize is also welcome.

Community
  • 1
  • 1
J.C
  • 633
  • 1
  • 13
  • 27
  • 1
    This is impossible. After a BSOD, the operating system is not even running. The CPU is halted. – Moby Disk Aug 13 '14 at 04:18
  • I know it's almost impossible, but when BSoD occurs, the kernel will dump some data from main memory, right? Do we have any chance let the Kernel dumps my data in any format, and I can recover them later? Even full memory dump is acceptable to me if I can still recover them. – J.C Aug 13 '14 at 05:40
  • No. By default the kernel does a minidump, which is just the information needed to debug the driver that crashed. It might be possible to dump all of the system memory, but that isn't useful to you either. – Moby Disk Aug 13 '14 at 05:55

1 Answers1

0

Since the buffer you have in your C# application is not written to disk for performance reasons, the only other place left for it is memory (RAM). Since you don't know how Windows manages your memory at the moment of the crash, we have to consider two cases: a) the log is really in RAM and b) that RAM has been swapped to disk (page file). To get access to all RAM of a BSoD, you have to configure Windows to create a full memory dump instead of a kernel minidump.

At the time of a blue screen, the operating system stops relying on almost anything, even most kernel drivers. The only attempt it makes is to write the contents of the physical RAM onto disk. Furthermore, since it cannot even rely on valid NTFS data structures, it writes to the only place of contiguous disk space it knows: the page file. That's also the reason why your page file needs to be at least as large as physical RAM plus some metadata, otherwise it won't be able to hold the information.

At this point we can already give an answer to case b): if your log was actually swapped to the page file, it will likely be overwritten by the dump.

If the buffer was really part of the working set (RAM), that part will be included in the kernel dump. Debugging .NET applications from a kernel dump is almost impossible, because the SOS commands to analyze the .NET heaps only work for a user mode full memory dump. If you can identify your log entries by some other means (e.g. a certain substring), you may of course do a simple string search on the kernel dump.

All in all, what you're trying to achieve sounds like a XY-problem. If you want to test your service, why don't you remove or replace the unrelated problematic PCI cards or test on a different PC? If blue screen logging is an explicit feature of your logging service, you should have considered this as a risk and evaluated before writing the service. That's a project management issue and off-topic for StackOverflow.

Unfortunately I have to confirm what @MobyDisk said: it's (almost) impossible and at least unreliable.

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
  • Thanks your explanation and pay attention on my question. I thought it is easy, but it's seems not. I'll consider how to go on my project in other way. – J.C Sep 10 '14 at 04:04