How to fix the BSOD?

zzzhhh

Honorable
May 13, 2018
90
3
10,535
I started to experience frequent BSOD a week ago. The reason of BSOD varies each time. Many BSOD threads say it is related to drivers. But Windows 10 can update drivers automatically. Actually I have manually updated all the drivers I know of, as well as the BIOS. I also tested the hard disk and the memory. There is no virus or malware. No overclock either. But there is still SBOD. So I can't help think that it is the Windows' buggy automatic update that causes these BSODs. Is it reported that recent Windows 10 update produces more BSOD?

If not, can you help me analyze the dump file to find out what driver(s) is the culprit? The dump file is here: https://www.dropbox.com/s/6a3bq4d1axd4puj/101318-5750-01.dmp?dl=0. Thank you.
 
I will get someone to convert dump files into a format I can read. A lot of the time it is old drivers that cause them, but as there are over 270 BSOD codes, many I have never seen, its not always so simple. It really depends on what codes you are getting.

Nvidia drivers have been causing lots of bsod recently, there is a firmware upgrade for the cards that can fix it.

Windows CAN update drivers, whether it does is another thing. If the manufacturers don't give MS newer drivers it can only find the old ones that may already be installed.
 
How does "someone" convert the binary dump file?

Where is nVidia firmware upgrade? The only thing I can find in Google is firmware update for DisplayPort 1.3 and 1.4, but I use DVI.
 
there is a windows debugging tool that can be used to read the dump files.
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/getting-started-with-windbg

a user called Gardenman has a program he has created that will present the info in an easier to understand format than what the debuigger above will likely show. He will answer this thread sometime in next 12 hours (he is likely asleep now)

That is the firmware I mean, but if you use DVI it may not help you.

always a chance someone else will come in before he does to answer question as a few people around here can read dump files.
 
some driver is corrupting kernel memory. looks like a programming mistake.
suspects would be your old backup software:
\C:\Windows\system32\ammntdrv.sys Tue Dec 25 00:46:37 2012

I think this always has issues:
DAEMON Tools Lite Virtual SCSI Bus Driver
\SystemRoot\System32\drivers\dtlitescsibus.sys Thu Sep 24 13:17:21 2015

you have nomachine remote control software installed:
could be a source.

I would also make sure your steel series hardware has all of its firmware updates,
and check for software updates from the vendor.

you might be able to force the system to bugcheck at the time of the data corruption rather than later when the corrupted data is used. to do this you would
start cmd.exe or powershell as an admin then run
verifier.exe /standard /all
then reboot your system.
be sure you know how to get into safe mode in case the system bugchecks during startup.
you will need to run:
verifier.exe /reset
to turn off verifier after you are done testing. (must do this or your machine will run slowly for ever)

when verifier finds a driver writing to data it does not own, verifier will call a bugcheck and write the drivers name in the memory dump file.

you might have to go through this process more than one time. DAEMON tools used to always fail the tests, you might have to remove it and test the other drivers.

Microsoft does not update your motherboard specific driver, they only provide generic versions.
you should always go to your motherboard vendors website and install the motherboard drivers.
(generally don't install the utilities)





 
Listen to what johnbl and Colif have to say.

I ran the dump file through the debugger and got the following information: https://pste.eu/p/FewQ.html

File: 101318-5750-01.dmp (Oct 13 2018 - 03:11:14)
BugCheck: [BAD_POOL_HEADER (19)]
Probably caused by: memory_corruption (Process: chrome.exe)
Uptime: 0 Day(s), 2 Hour(s), 22 Min(s), and 18 Sec(s)

Motherboard: https://www.asus.com/us/Motherboards/PRIME-Z270M-PLUS/

I can't help you with this. Wait for additional replies. Good luck.
 


Thank you very much for the reply, johnbl. I only considered drivers that are associated with real hardware, but forgot those with software services. I have uninstalled the AOMEI Backupper, DAEMON Tools Lite, an X server on Windows and upgraded NoMachine (released recently so should be working). The verifier is a good tool to list all drivers. I checked all of them and make sure the remaining drivers with unknown provider info are all benign and I know where they are from. I also blocked automatic update of Windows 10 just in case. The BSOD happened at least once per day, so I'll wait to see if there is any in upcoming days. Will let you know the result. Hope that is all.

Oops, there was a BSOD immediately after this post, but there's no dump file saved. So there is still something else ...
 
Purely based on fact Chrome crashed, try updating your LAN drivers. The LAN drivers on system are dated Mar 04 2016 but the latest on the Asus web site are dated Dec 28 2017

Try updating Intel Management Engine Interface as the installed version is older than your BIOS and might also cause conflicts - it is dated Apr 04 2017 on system but ones on Asus site dated Dec 28 2017

https://www.asus.com/us/Motherboards/PRIME-Z270M-PLUS/HelpDesk_Download/
 
use this tool, https://docs.microsoft.com/en-us/sysinternals/downloads/autoruns
find the menu item to hide microsoft entries, and hide empty entries.
then you can uncheck drivers you do not want to load, do this on suspect drivers and reboot to see if you still bugcheck. you can check the driver and reboot to get the driver to load again. you can delete entries so the driver will never load.

time consuming but it is better than uninstalling all of the programs if you don't have someone to debug for you.


---------------------
what is this driver?
C:\Windows\System32\Drivers\socperf3.sys Sun Jul 29 04:31:26 2018
not a good sign when I can not find the driver name on google.

verifier was not turned on in the memory dump. need the kernel dump c:\windows\memory.dmp
the system bugchecked because a driver overwrote some memory. it looks like a programming mistake
since the memory address was 22 which is more likelhy a memory header size. a very common error.

you would have to have a kernel memory dump so the pooltag could be found. verifer should be set.
otherwise, you should do a wipe of the system, and a clean install, full windows updates and motherboard drivers only.
make sure you system is stable before you install the 35 3rd party drivers.




 
Gardenman and I wonderd that same thing earlier John... socperf3.sys is part of VTune Amplifier XE 2017, made by Intel. There are 4 drivers from the same date that are all Intel drivers

sepdal.sys = PMU Arbitration Service driver - Intel(R) Software Development Products
sepdrv5.sys = Intel Sampling Enabling Product driver
vtss.sys = Intel(R) Software Development Products
socperf3.sys = VTune Amplifier XE 2017

https://software.intel.com/en-us/forums/intel-vtune-amplifier/topic/685408
 
obscure drivers are more likely to have programming mistakes.
looks like the memory address used is actually the bufferlengh of a driver memory structure.

these are just very hard to find without verifier or a kernel memory dump.
the user only had verifier on for two drivers (previous thread), and it was off for the memory dumps I looked at.



driver overwrites data of another driver, then the second driver used the overwritten data. the buffersize field gets used as a address and since it is not zero it does not get trapped. but later fails because it is a bogus memory location.

small data corruptions are hard to find. most of the time a driver corrupts its own data but sometimes it will corrupt another drivers data. You just don't know without the pooltags.







 
overall, i think your malware is not infecting the system correctly.
it is something you are running in usermode.
it would require a full memory dump to see what is going on. a kernel memory dump would also help, at least it would show the names of what was run.

most likely it is being installed as a generic service host, you would have to run
https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
to figure out which copy of the svchost.exe is the cause.

------------
google {ABD61E00-9350-47e2-A632-4438B90C6641}
it looks like an attack by malware:https://www.trendmicro.com/vinfo/us/threat-encyclopedia/malware/pe_fujacks.eg-o
---------------
are you attempting to run a debugger from a windows subsystem?
did a windows error detection attempt to connect and debug your machine?

search your c: drive for *.dmp files and see if there is a live window debug session log or .dmp file



---------------


the second bugchek was INVALID_PROCESS_DETACH_ATTEMPT

-------------------
first bugcheck looks like a user mode program terminated a process
looks like the process terminated was svchost.exe

need a kernel dump to debug this, a minidump just does not save the proper info.


first minidump has a extra human interface driver installed.
hidparse_fffff80372600000 \SystemRoot\System32\Drivers\hidparse.sys 153CE4E8
is colliding with this one:
\SystemRoot\System32\HIDPARSE.SYS 153CE4E8


something wrong with the setup for some reason;
bios interface is working in the debugger:
BIOS Version 1205
BIOS Starting Address Segment f000
BIOS Release Date 05/14/2018
Manufacturer ASUSTeK COMPUTER INC.
Product PRIME Z270M-PLUS
Version Rev X.0x
4 banks of memory, all the same
Speed 2133MHz
Manufacturer Corsair
Part Number CMK16GX4M2B3000C15
Processor Version Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz
Processor Voltage 8bh - 1.1V
External Clock 100MHz
Max Speed 8300MHz
Current Speed 3200MHz
3: kd> !sysinfo cpumicrocode
Initial Microcode Version: 000000c2:00000000
Cached Microcode Version: 000000c2:00000000
Processor Family: 06
Processor Model: 5e
Processor Stepping: 03
 
Hi, johnbl, so you suspect it is malware that causes BSOD? So it is confirmed that it turns out the BSOD has nothing to do with drivers being out-of-date? For the remaining part of your reply. I have no idea what you were talking about. So would simply installing an anti-virus like trendmicro fix BSOD?
 
I would use autoruns to remove the extra hidparser.sys driver
and I would look at all of the services running and see what they are doing. one of them was killing threads and attempting to hack in. That means you already have a service running that is trying to hack your system.

I generally don't work on this type of problem. I just run malwarebytes and see if it finds and fixes the problem.
It is often better to wipe, then install the antivirus before you attempt to install the various software.
make sure you download new copies of the software, and scan it before you install. some sites will serve up infected software. it is hard to fix malware that attempts to hide from you. you miss one piece and it gets reinstalled.
the new windows build has a bunch more patches that block malware infections. looks like it causes a bugcheck when the infection occurs. it should stop the spread but still breaks your system so you have to go to safe mode and reinstall a recovery point.







 
So you suspect malware infection because there are two hidparser.sys. Does this happen in the first minidump file? Does the malware use different driver file to attack so next time the duplicated driver would change from hidparser.sys to something else?

Will upload a complete memory dump file when BSOD happens again.