Windows 10 BSOD paradise, multiple drivers and dumps

[jcgriff2]

Agree... fltmgr.sys must start up/be loaded before epp.sys can.

 

[ravenize]

Ok disabled all hardware drivers & software drivers that had BSOD in driver verifier, and still was receiving bsods, including with fltrmgr which continued after disabling epp.sys which relies on filtrmgr. The only driver I have not disabled is sandboxie, which I doubt is the source of this issue and is necessary to remain secure during online browsing... sandboxie staff are adimant after looking at the dump its just driver verifier overreacting

"You don't seen to have liked my original response, but I will make it again. Driver verifier has never worked with Sandboxie. You can search this forum and see the posts that go back over 10 years.
search.php?keywords=driver+verifier

For example, the text of the error in the DMP posted in your other thread is "Code Integrity Issue: The caller specified an executable pool type. (Expected: NonPagedPoolNx)"

The use of NX memory requirement was added in Win 8 (Sandboxie still supports Win 7). The additional error text "A device driver attempting to corrupt the system has been caught." is a gross exaggeration by Microsoft. The driver verifier is actually reporting that SbieDrv.sys has allocated R/W memory which has does not meet this new NX memory safety requirement. No system "corruption" has occurred.

SbieDrv.sys is a driver that has close interaction with the OS. To make SbieDrv.sys fully compliant with Win 7 - Win 10 driver verifiers will require a lot of changes that will show no benefit to the user -- if it is even possible. As I said before, SbieDrv.sys is not a normal, self-contained driver. It intercepts a lot of Windows system calls and interacts tightly with Windows. Driver verifier does not like these types of interactions. This has never been a major problem for anyone in the past.

We have not had a genuine BSOD reported for Sandboxie in a long time. When they are reported, they are immediately fixed. Since no one else is reporting any problems, and none have shown up in testing, the problem on your machine most likely lies elsewhere."

 

[ravenize]

On Mon 3/25/2019 4:31:12 AM your computer crashed or a problem was reported
crash dump file: C:\Windows\Minidump\032519-11718-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x1B35E0)
Bugcheck code: 0x18 (0xFFFFBB01274FD7A0, 0xFFFFE08605E67E70, 0x1, 0xFFFFFFFFFFFFFFFF)
Error: REFERENCE_BY_POINTER
file path: C:\Windows\system32\ntoskrnl.exe
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: NT Kernel & System
Bug check description: This indicates that the reference count of an object is illegal for the current state of the object.
This bug check belongs to the crash dump test that you have performed with WhoCrashed or other software. It means that a crash dump file was properly written out.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.

On Mon 3/25/2019 4:31:12 AM your computer crashed or a problem was reported
crash dump file: C:\Windows\MEMORY.DMP
This was probably caused by the following module: ntkrnlmp.exe (nt!memset+0x896F0)
Bugcheck code: 0x18 (0xFFFFBB01274FD7A0, 0xFFFFE08605E67E70, 0x1, 0xFFFFFFFFFFFFFFFF)
Error: REFERENCE_BY_POINTER
Bug check description: This indicates that the reference count of an object is illegal for the current state of the object.
This bug check belongs to the crash dump test that you have performed with WhoCrashed or other software. It means that a crash dump file was properly written out.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.

Oddly I have had 3 BSOD's of late that have pointed to non existent and or zero byte files; unless this file is being compiled somewhere and resident in memory only, because a search on the computer for this file shows nothing. Previously the only file that existed with this name ntkrnlmp.exe was a 0 byte file was located under c:\symcache, I have since deleted & cannot locate anywhere; however the latest dump suggests this file was the culprit (old picture:



The first time this occurred, I also located 2 DCP timers called by an undetectable kernel module:



This time I do not see any suspicious DCP activity.

 

[ravenize]

The dumps are available right here, next stop memtest. Already ran linpack extreme in windows for 5-10 hours without a hitch. Never had this issue in windows 7 mind you. MEGA

 

[ravenize]

Will try disabling system mandatory bottom up aslr, according to source "Also note that in the past, enabling system-wide mandatory ASLR could cause problems if older AMD/ATI video card drivers are in use. This issue was addressed in the Catalyst 12.6 drivers released in June, 2012."

 

[ravenize]

Some notes a week or two ago when I suspected DoS BSOD:

There was just one DCP Timer image at first, which I removed with PChunter, then after a reboot two appeared. I did not unhook those two just to see what may come of it. Then I looked up crashes related to my motherboard, P5Q Pro, to see if BSOD's are common due to a 10 year old BIOS, I opened multiple websites describing "DRIVER_IRQL_NOT_LESS_OR_EQUAL", and IMMEDIATELY I had a BSOD that was "DRIVER_IRQL_NOT_LESS_OR_EQUAL", which is the first time I remember seeing this in a very long time... certainly long before I began posting them here. Then upon booting into windows I had another BSOD immediately after I logged on. This is the first time I have ever experienced BSOD that immediate. Usually it takes a day or so. Upon rebooting yet again, there were no "unknown images" listed in DPC Timers.

I later fixed MBR, ran trim, sfc, chkdsk, shut down pc cold, cleared swap on boot, swap was encrypted so any malware hiding in there would not be detected by AV. Havent seen any rogue DCP timers since then.

 

[ravenize]

Have you ever used or heard of volatility? You may find this of interest: Hunting malware with memory analysis (via Passle)