Livekernelreports что это за папка windows 10

Last reviewed and updated: 10 August 2020

Even though they may feel spontaneous, a system crash is always an explicit decision by a kernel component to bring the machine down. Sometimes the machine is in such a bad state that immediately resetting the entire system is the only reasonable thing to do. For example, if the Memory Manager detects a corruption in the operating system we can’t simply let the corruption pass and possibly make things worse, so it crashes the machine to get out of a bad situation.

At this point we’d also like to know why the system was in a bad state, so the O/S writes the contents of memory out into a crash dump file. Some poor soul can then be chained to a chair and forced to stare at the dump in WinDbg until the bug is found.

Given their usefulness, it might also be beneficial to have a crash dump not only in cases that are fatal but in ones that are simply undesirable. For example, imagine that NDIS tries to reset your network adapter but the reset takes too long. We don’t necessarily want to crash the machine because of this, but we might want to generate a crash dump so we can analyze the state of the system and figure out what’s causing the delay.

This is the idea behind the Live Kernel Reports feature introduced in Windows 8. I personally didn’t notice this feature until 2019, and it instantly intrigued me. Basically, any driver in the system can call the undocumented DbgkWerCaptureLiveKernelDump API and generate a kernel summary dump and/or a minidump in the C:\Windows\LiveKernelReports folder. This allows each driver to decide what conditions might require some additional scrutiny and non-intrusively generate a crash dump for further study. Check out the folder on your own system right now and you might even see a few dump files in there.

Out of curiosity I wanted to see which Windows drivers used this functionality on a clean install of 19H1 and received quite a few hits:

0: kd> x *!_imp_DbgkWerCaptureLiveKernelDump
ffff8ec0`fdb596d0 win32kfull!_imp_DbgkWerCaptureLiveKernelDump = 
ffff8ec0`fdeaf378 cdd!_imp_DbgkWerCaptureLiveKernelDump = 
fffff803`d2086250 mrxsmb!_imp_DbgkWerCaptureLiveKernelDump = 
fffff803`d21b26e8 cldflt!_imp_DbgkWerCaptureLiveKernelDump = 
fffff803`d25021c8 srv2!_imp_DbgkWerCaptureLiveKernelDump = 
fffff805`1f7db5a8 Wdf01000!_imp_DbgkWerCaptureLiveKernelDump = 
fffff805`1f8380f0 WppRecorder!_imp_DbgkWerCaptureLiveKernelDump = 
fffff805`1f97c658 ACPI!_imp_DbgkWerCaptureLiveKernelDump = 
fffff805`1fa2c1e8 intelpep!_imp_DbgkWerCaptureLiveKernelDump = 
fffff805`1fb95040 pdc!_imp_DbgkWerCaptureLiveKernelDump = 
fffff805`201264b0 Ntfs!_imp_DbgkWerCaptureLiveKernelDump = 
fffff805`2057a158 UsbHub3!_imp_DbgkWerCaptureLiveKernelDump = 
fffff805`206a52d8 ndis!_imp_DbgkWerCaptureLiveKernelDump = 
fffff805`209ef600 tcpip!_imp_DbgkWerCaptureLiveKernelDump = 
fffff805`20b042e8 fwpkclnt!_imp_DbgkWerCaptureLiveKernelDump = 
fffff805`20c6a608 volsnap!_imp_DbgkWerCaptureLiveKernelDump = 
fffff805`20d2a3b0 USBXHCI!_imp_DbgkWerCaptureLiveKernelDump =  

Note that this only indicates the loaded drivers uses this functionality. A string search in the C:\Windows\System32\Drivers directory uncovered even more.

To be fair, in general these Live Kernel Reports aren’t terribly interesting. After all, they represent non-fatal failures and thus shouldn’t be too much bother to the user. However, I spend a lot of time debugging system crashes that point to no obvious culprit. In those cases I like to think about what’s different about the crashing system that might give me some new clues as I try to solve the riddle. Maybe there’s a component that’s been logging errors to the Event Log for the last month. Or maybe there’s a bunch of minidumps from previous crashes that the user didn’t even notice. The crash dumps in the Live Kernel Reports folder work in the same way. For example, maybe the NIC has been generating Live Kernel Reports since the time the driver was last updated.

But I Want Live Kernel Reports Too!

I also happen to be a dev, and so I want Live Kernel Reports for my drivers too! Given that it’s an entirely undocumented feature I’m not foolish enough to want to ship code that generates them, but I see a huge value here in terms of testing. I’d like to let the test team go crazy beating on our code while the driver silently generates Live Kernel Reports along with error logs for the development team to inspect. Sure, we could just crash the machines, but in many cases that’s unnecessary and we want to see how our code recovers from error conditions anyway.

So, after kicking that around as a, “wouldn’t that be nice?” idea for a while, I finally got around to doing a quick feasibility study by generating a Live Kernel Report from a test driver. I’m not Mr. Reverse Engineer, but I can fumble around enough to come up with a function prototype with enough parameters to get me going. Note that I gave up after the first 6 parameters (mostly due to lack of time and interest, as you’ll soon see that this experiment quickly hit a brick wall):

EXTERN_C
_IRQL_requires_(PASSIVE_LEVEL)
NTKERNELAPI
NTSTATUS
DbgkWerCaptureLiveKernelDump(
    _In_z_ PWCHAR ComponentName,
    _In_ ULONG LiveDumpCode,
    _In_ ULONG_PTR LiveDumpParam1,
    _In_ ULONG_PTR LiveDumpParam2,
    _In_ ULONG_PTR LiveDumpParam3,
    _In_ ULONG_PTR LiveDumpParam4,
    _In_ ULONG_PTR I,
    _In_ ULONG_PTR Dont,
    _In_ ULONG Know
    );

It took me a bit to get to that point and I was pretty excited when my module linked and loaded on the target. I then called the API and…. (wait for it)….. nothing happened. No crash, no debug output, no Live Kernel Report, nothing. Never one to give up so easily, I poked around and saw that there were DbgPrintEx calls being made inside this API and this led to two debug print filters that can be set to get more information:

0: kd> ed nt!Kd_WER_Mask f
0: kd> ed nt!Kd_CRASHDUMP_Mask f

With those flags set I received much more interesting output when I tried to generate the Live Kernel Report:

WERKERNELHOST: WerpCheckPolicy: Requested Policy is 2 
WERKERNELHOST: System memory threshold met. Memory Threshold 274877906944 bytes, SystemMemory 8589398016 bytes
WERKERNELHOST: System threshold time not met. Threshold time 132051744578202800, Current time 132047486278525109
WERKERNELHOST: WerpCheckPolicy: Requested Policy 2 is higher than granted 0
WERKERNELHOST: CheckPolicy throttled dump creation for Component 
DBGK: DbgkWerCaptureLiveKernelDump: WerLiveKernelCreateReport failed, status 0xc0000022.

Note the highlighted message about the “system threshold time” not being met. Presumably the numbers specified are timestamps (in decimal), so we can translate them into system times using the .formats command. Here is the result for the threshold time:

0: kd> .formats 0n132051744578202800
Evaluate expression:
  Hex:     01d5245c`af8decb0
  Decimal: 132051744578202800
  Octal:   0007251105625743366260
  Binary:  00000001 11010101 00100100 01011100 10101111 10001101 11101100 10110000
  Chars:   ..$\....
  Time:    Sun Jun 16 12:00:57.820 2019 (UTC - 4:00)
  Float:   low -2.58159e-010 high 7.8296e-038
  Double:  7.89244e-300

And for the current time:

0: kd> .formats 0n132047486278525109
Evaluate expression:
  Hex:     01d5207d`391d60b5
  Decimal: 132047486278525109
  Octal:   0007251007647107260265
  Binary:  00000001 11010101 00100000 01111101 00111001 00011101 01100000 10110101
  Chars:   .. }9.`.
  Time:    Tue Jun 11 13:43:47.852 2019 (UTC - 4:00)
  Float:   low 0.000150087 high 7.82905e-038
  Double:  7.88679e-300

Clearly the code is trying to avoid generating too many Live Kernel Reports and thus has put some arbitrary deadline in the future for the next time a dump may be written. I searched but could not find a way to bypass this (i.e. a, “no, please do wear out my SSD and fill my drive, I don’t care!” flag) but alas did not find one. This dashed any and all hopes I had for using this as a testing mechanism in the lab.

Of course, I simply could not leave this alone until I saw my driver generate a Live Kernel Report. Using the debugger I NOP’d out the offending check and, hurray, I saw my dump file!

Картинка с сайта: www.osr.com

However, not too long later the dump file disappeared on me. Checking out Process Monitor, I can see that sometime after the Live Kernel Report is generated WerFault.exe runs and cleans out the folder.

• 

  Картинка с сайта: www.osr.com

This doesn’t appear to happen every time and for every dump, but there’s some algorithm behind the scenes to make sure this folder doesn’t grow unbounded.

Not Generically Useful, But Still Useful

Sadly, but not surprisingly, this mechanism is way too undocumented and special purpose built to be generically useful. I’ll continue to look at Live Kernel Reports as part of analyzing systems though and through this experiment I’ve learned that just because there aren’t any dumps in the Live Kernel Reports folder it doesn’t mean that they aren’t being generated.

Some time back, I ran into a bit of a space crunch on the C: drive of my laptop which runs Windows 8.1. On digging a bit, I found a 2GB+ file at C:\Windows\LiveKernelReports\WinsockAFD-20150114-1722.dmp. Now, this was the first time I had seen a folder called LiveKernelReports and definitely the first time that I had seen a dump file with the name WinsockAFD*.dmp.

Important note: if you are not a developer and came here trying to figure out what to do with the files in this folder, please proceed directly to the ‘So What?’ section below.

Inside the Dump File

The first thing I did (of course ) was to open up the dump file under the WinDbg debugger. In kernel mode dumps, the !analyze –v command generally gives good analysis results, so I decided to start from there (full output of !analyze is at the end of this post as an Appendix).

Firstly, the bugcheck code was 0x156. If you are a developer, and you have the Windows 8.1 SDK, you will see this file C:\Program Files (x86)\Windows Kits\8.1\Include\sharedbugcodes.h which has the bugcheck names. 0x156 is WINSOCK_DETECTED_HUNG_CLOSESOCKET_LIVEDUMP.

Second, this bugcheck, unlike most of the ones we know, did not ‘crash’ or ‘blue screen’ the system.

Live Kernel Dumps

All of this is great, but what’s really happening here? How come I got kernel dumps without the system ‘crashing’? Well, the answer is that in Windows 8.1 the Windows development team added some great reliability diagnostics in the form of ‘Live Kernel Dump Reporting’. With this feature, certain Windows components can request a ‘live dump’ to be gathered. In my above case, both a minidump (~ 278KB) and a ‘larger’ dump (~ 2GB) were gathered when the AFD (Ancillary Function Driver for WinSock) runtime detected that a socket did not close ‘in time’ (see bold sections in the Appendix for more information.)

The Windows Error Reporting feature will then use the minidump to help the Windows development team figure out if this is a ‘trending’ issue, prioritize it and then hopefully fix it if it is due to an issue with Windows. The ‘larger’ dump which I mentioned above is not normally uploaded unless the development team ‘asks’ for it again via the Windows Error Reporting and Action Center mechanisms (to ultimately give the end user control on what gets submitted.)

So What?

That is the million dollar question As an end user, you may be wondering what to do with these types of dump files. The advice I can give you is: if the dump files are causing you to go very low on disk space, you can probably move the dump file off to cheaper storage, like an external HDD. BUT if you are repeatedly getting these dump files, it may be advisable to check for any third party drivers, especially anti-virus products or any other network related software. Sometimes older versions of such software may not ‘play well’ with Windows 8.1 and may be causing a stalled network operation, in turn leading to these dump files.

If you are an IT Pro and seeing these dump files on server class machines and / or on multiple PCs, you would do well to contact our CSS (Customer Service and Support) staff who can guide you further on why these dump files are occurring and what should be the course of action.

In Closing

I hope this helps understand this system folder and why it plays an important role in improving the reliability of Windows. If you are interested in this topic, I highly recommend this talk from Andrew Richards and Graham McIntyre, who are both on the Windows Reliability team. They explain how the OCA / WER mechanism works. Amazing stuff, check it out!

Appendix: !analyze –v output

0: kd> !analyze -v
…

WINSOCK_DETECTED_HUNG_CLOSESOCKET_LIVEDUMP (156)
Winsock detected a hung transport endpoint close request.
Arguments:
…

DEFAULT_BUCKET_ID:  WINBLUE_LIVE_KERNEL_DUMP

BUGCHECK_STR:  0x156

…

STACK_TEXT:
…

ffffd001`28e46660 fffff803`bdddd64d : ffffffff`800026bc 00000000`00000000 ffffc001`1f52ec00 00000000`00000000 : nt!DbgkpWerCaptureLiveFullDump+0x11f
ffffd001`28e466c0 fffff801`21b7e3b4 : 00000000`00000001 ffffd001`28e46889 00000000`00000048 ffffe000`3e9afda0 : nt!DbgkWerCaptureLiveKernelDump+0x1cd
ffffd001`28e46710 fffff801`21b7b4ff : ffffe000`3e9afda0 00000000`0000afd2 ffffe000`3e9afd00 00000000`00000002 : afd!AfdCaptureLiveKernelDumpForHungCloseRequest+0xa8
ffffd001`28e46770 fffff801`21b89cad : ffffe000`3e9afda0 ffffd001`28e46889 00000000`0000afd2 ffffd001`28e46808 : afd!AfdCloseTransportEndpoint+0x64ef
ffffd001`28e467d0 fffff801`21b89674 : 00000000`00000001 ffffe000`42d71010 00000000`00000000 ffffe000`3e9afda0 : afd!AfdCleanupCore+0x14d
ffffd001`28e468f0 fffff803`bdc47349 : ffffe000`42d71010 ffffe000`3d3fd080 00000000`00000000

…