After a few minutes of reading around – sounds like a broken AV to me. You wrote below CLFSYS.SYS – did you mean clfs.sys? Because I don’t think there is a CLFSYS.SYS, which would lead me to think “virus”.
This is also a worthwhile read: https://msdn.microsoft.com/en-us/library/windows/hardware/ff557386(v=vs.85).aspx From: listsad...@lists.myitforum.com [mailto:listsad...@lists.myitforum.com] On Behalf Of Charles F Sullivan Sent: Thursday, December 15, 2016 3:45 PM To: ntsysadm@lists.myitforum.com Subject: [NTSysADM] Analyzing Minidumps This is something I find myself needing to do only occasionally. I usually use BlueScreenView to read minidumps after a crash because it’s quicker and easier than windbg. Regardless of the tool, when multiple crashes are caused by the same device driver, it’s pretty straightforward as to the culprit. In the case of system drivers along with ntoskrnl.exe being listed as the cause, it’s not so apparent, so I’m not really sure what I’m seeing. We had a Windows 2012 R2 VMware VM that suddenly began crashing on a Sunday night when nothing such as a backup or other intense operation was happening. The server kept crashing after the initial time and the only way to stop it was to boot into Safe Mode and we ended up rebuilding the server. Along with ntoskrnl.exe on each crash, each of the 12 minidumps lists one of these as the cause. This is from the first crash and happened only once: Fs_Rec.sys (File System Recognizer Driver) This was listed as the cause on 9 of the subsequent crashes. I believe it’s from the Guardium application, which is used for monitoring of database servers. Nptrc.sys This one twice: CLFSYS.SYS (Common Log File System Driver) The Bug Check String for all of them is REFERENCE_BY_POINTER and the Bug Check Code is 0x00000018. Is this enough information for someone to give an opinion as to what is the likely root cause, or maybe what else to look for? It’s hard for me to blame the Guardium application since it wasn’t shown as the cause on all of the crashes.
