Multiple BSOD and CryptSvc Running Repeatedly & Hogging CPU

[SteveECrane]

Hello ... and good afternoon!

Over a month ago, my Windows 10 Pro laptop performed a Windows Update which, until then, I had previously postponed and then prevented. For some reason, this update previously screwed with my system (a Win10 installation I run almost solely as a Steinberg Cubase-based music DAW) when it first attempted to install late last year. At that time I rolled back all the changes and employed some hacks I obtained online in order to prevent Windows Update from automatically running and forcing me to install said update(s) - 'improvements' I did not need nor want. (Note: Music DAW's are highly-specialist environments which require fine-tuning to run optimally, especially in respect of driver versions, many of which can cause high DPC latency: graphics, Wi-Fi, Ethernet, power management settings, etc.).

Thankfully, all was fine until...

Somehow, around Christmastime, something must've altered to negate the hack I had applied because my system once again downloaded the aforementioned update (and some other stuff) in order to attempt another install. Due to family and health issues, I merely postponed the update for the maximum time available, namely 30 days ... and then promptly forgot about preventing it from taking place. My bad!

So...

I awoke one Monday around 3 weeks ago to find the updates had been applied ... and my system was entirely unusable as it was stuck in some OOBE loop. I subsequently spent 4 days nursing it back to some resemblance of health such that I could at least log on! However, there were no Restore points remaining to roll back the previous changes (I manually create them regularly before I make any significant changes but they were all now gone - ALL of them!) and the ones generated automatically were missing too, with the system restore function itself now turned off as well(!). None of the automatic Windows recovery options (or any involving my manual intervention) which ran after multiple re-boots would work either! Trust me, I exhausted everything!

Suspecting malware or an infection of some kind, I managed to run Malwarebytes but it found nothing. One critical thing I did notice, however, was that whenever ANY app or system function was performed - from clicking on menus to running system apps - a svchost.exe hosted CryptSvc process would hog circa 20% of the CPU resource for around 1-2 minutes before 'allowing' the required program to execute. Killing C:\WINDOWS\system32\svchost.exe -k NetworkService -p -s CryptSvc using the SysInternals Task Manager replacement (Process Explorer) would immediately allow the underlying app to run, executing near-instantaneously.

This is how I've had to manage for almost 3 weeks. Recording and processing music is nightmarish!!!

Unfortunately, there is so much music-production software installed on this machine (including some legacy s/w I don't believe I have the installers for) that I could not afford the time to scrub it and start again - which would now be my first choice - as this is a 3-4 day exercise minimum and I utilise this laptop to teach with. [Note: I did have a full SSD back-up of the system drive with all the apps but I ended up employing it for more music production sample libraries I was bought for Christmas and never got around to replacing them and backing up. :-( Yeah, yeah, I know!!!). Ergo, I set about repairing the damage by initially running SFC /SCANNOW:

Windows Resource Protection found corrupt files but was unable to fix some of them.
For online repairs, details are included in the CBS log file located at
windir\Logs\CBS\CBS.log. For example C:\Windows\Logs\CBS\CBS.log. For offline
repairs, details are included in the log file provided by the /OFFLOGFILE flag.


On the basis of this, I then attempted to employ DISM /Online /Cleanup-Image /RestoreHealth ... but got nowhere:

Deployment Image Servicing and Management tool
Version: 10.0.19041.1
Image Version: 10.0.19041.1
[==========================100.0%==========================]
Error: 0x800f081f
The source files could not be found.
Use the "Source" option to specify the location of the files that are required to restore the feature. For more information on specifying a source location, see Configure a Windows Repair Source.
The DISM log file can be found at C:\WINDOWS\Logs\DISM\dism.log


Following these errors, in order to remedy what appeared to be a corrupted WinSXS file repository and required files residing elsewhere, I downloaded a suitable Win10 ISO from Microsoft and attempted to use the following DISM command: DISM /Online /Cleanup-Image /RestoreHealth /Source:ESD:D:\Source_Install_ESD\Install.esd:6 /LimitAccess which resulted in this:

Deployment Image Servicing and Management tool
Version: 10.0.19041.1
Image Version: 10.0.19041.1
[==========================100.0%==========================]
Error: 0x800f081f
The source files could not be found.
Use the "Source" option to specify the location of the files that are required to restore the feature. For more information on specifying a source location, see [URL='https://go.microsoft.com/fwlink/?LinkId=243077']Configure a Windows Repair Source[/URL].
The DISM log file can be found at C:\WINDOWS\Logs\DISM\dism.log


Note: The source file(s) DO exist - I'd verified them! Some online posts indicated that Win10 could not address an ESD directly (contradicting others!), so I attempted to create a WIM instead, having checked the Win10 ISO download with this DISM/Get-WimInfo /WimFile:D:\Source_Install_ESD\install.esd :

Index : 6
Name : Windows 10 Pro
Description : Windows 10 Pro
Size : 15,583,732,666 bytes

and then ran this DISM /export-image /SourceImageFile:D:\Source_Install_ESD\Install.esd /SourceIndex:6 /DestinationImageFile:D:\Source_Install_WIM\Install.wim /Compress:max /CheckIntegrity

which resulted in this:

Deployment Image Servicing and Management tool
Version: 10.0.19041.1
Exporting image
[======== 15.0% ]
Error: 605
The specified buffer contains ill-formed data.
The DISM log file can be found at C:\WINDOWS\Logs\DISM\dism.log


I double-checked the health of everything first using: DISM /Online /Cleanup-Image /CheckHealth and received:

Deployment Image Servicing and Management tool
Version: 10.0.19041.1
Image Version: 10.0.19041.1
The component store is repairable.
The operation completed successfully.

and this: DISM /online /cleanup-image /scanhealth resulted in:

Deployment Image Servicing and Management tool
Version: 10.0.19041.1
Image Version: 10.0.19041.1
[==========================100.0%==========================]
The component store is repairable.
The operation completed successfully.


I've also tried stopping Cryptographic Services and renaming Catroot to Catrootold to force a rebuild of that, as well as deleting the HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates\Root entry forcing it to rebuild the Root Cert store.

I even tried re-installing a Win10 installation over the current one using the Win10 image I had downloaded ... but that failed too! Absolutely nothing has worked - I am still having to kill the CryptSvc process whenever I open a new app or starting a new process if I want either to complete in a reasonable timeframe!

Finally, MemTest86 reports no errors either ... hence I'm here!

So, attached is the results of the latest SysnativeFileCollectionApp.exe v5.0.1 utility suite. Any advice or approach gratefully received.


PS It seems the forum is taking the ": D" - without whitespace - and turning it into a Smily!!! I'm not sure how to prevent this...

 

[SteveECrane]

The Speccy system hardware report.

 

[ubuysa]

What was the KB number of the Windows update that you believed was giving you problems? In general, if a Windows update causes issues its because there is some other (typically third-party) driver or module that's causing the update to fail or misbehave. Personally I hate reading about hacks obtained from the Internet to prevent Windows updates being installed. That's never wise IMO, it's far more sensible to discover why a particular update won't install than to try and hack Windows to stop it. It makes it harder for us to help you, because it's hard for us to trust the integrity of you Windows system now.

The msinfo32 output and the System and Application logs are missing from your SysnativeFileCollection.zip file. Is there a reason for that? Did you delete anything before uploading the file? These logs are a particularly useful source of troubleshooting data.

That said, my initial thoughts having looked through the four dumps that were uploaded is that bad RAM is the most likely cause here. Three of the dumps are similar, they're 0x1A bugchecks caused by a page table entry being corrupted. This is often caused by a rogue (third-party) driver, but can also be caused by bad RAM (the System and Application logs would have been useful here). The fourth is a 0x3B bugcheck with a 0xC0000005 exception code, indicating an invalid memory reference. In the call stack of this dump there are only Microsoft functions called and that's often a good indication of a hardware cause.

I also note from your RAM report that you may have mismatched RAM sticks installed...

Manufacturer	Part Number	Serial Number	Speed	Capacity	Bank Label	DIMM	Form Factor	Data Width
Hynix/Hyundai	HMT351S6CFR8A-PB	0040820B	1600 MHz	4 GB	BANK 0	Bottom-Slot 2(right)	12	64
01BA		00000000	1600 MHz	8 GB	BANK 1	Top - Slot 2 (under)	12	64
Hynix/Hyundai	HMT351S6CFR8C-PB	4F2AEE16	1600 MHz	4 GB	BANK 2	Bottom-Slot 1(left)	12	64
Hynix/Hyundai	HMT351S6EFR8A-PB	2FCC8FA0	1600 MHz	4 GB	BANK 3	Top - Slot 1 (top)	12	64

What RAM is that '01BA' stick? It's a different size to the others and may well have different timings. Mixing RAM is a well-known cause of problems. Ideally all RAM should be bought in a single pack of matched sticks to ensure that they play nicely together.

Given what I've seen in the dumps and in that RAM report I would suggest you remove that '01BA' stick and see whether the system is stable (make sure the other three sticks are in the correct slots according to your motherboard manual). If you still get BSODs without that RAM stick installed then please run the SysnativeBSODCollectionApp again and upload a new output file.

BYW the high CPU usage of CryptSvc isn't terribly unusual, this is the Windows Cryptographic Service. Killing Windows processes is also not generally a good idea, it can leave your system in an unstable state.

 

[SteveECrane]

UBUYSA,

Hello ... and good morning!

Thank you for taking the time to respond. To clarify a few points:-

1. I simply cannot have Windows altering a stable system in any way - DAW's often take an inordinate amount of time to tweak and tailor to be able to perform appropriately (these are not generic systems and a 'fast' CPU is almost pointless if there are any underlying ISR/DPC issues) - especially one which is used for commercial purposes.
   Microsoft have very little understanding of what constitutes a stable audio system running ASIO apps, I do. Ergo, the wholly necessary 'hack'.
   On this basis, MS and any other developer whose s/w is on this platform will not be allowed any control to be exercised over my DAW at their whim, something most studio owners will confirm is precisely how they operate. In fact, my studio-based DAW is barely ever connected to the internet; again, this is something many other studio owners will also confirm.
   
   
2. The above is also the reason for the age of this system - it works (worked!?) and I operate under the premise, "...if it ain't broke, don't fix it". Furthermore, it has a ExpressCard slot for a portable DSP card (from Universal Audio) for when I'm recording in-the-field which is entirely unavailable on more modern systems.
   
   
3. The 'hack' was nothing dodgy that was downloaded and 'installed' - I'm not naïve (and this isn't my first rodeo!) - but, rather, several registry entry amendments I researched and understood completely before applying, coupled to a GPEdit mod I applied in order to disable the update process in its entirety. They were posted on MS's very own pages!
   As you will be aware, Windows users once had full control of the update process and I was simply exercising my right to retain control of my laptop and this unnecessarily mandated process following several MS screw-ups on other systems I use.
   Furthermore, the same 'hack' is applied to the main DAW in my music studio and there are absolutely no ill effects; quite the contrary, in fact.
   However, I admire your trust in Microsoft's update process for delivering a stable system!
   
   
4. The high CPU use of CryptSvc, per se, is not the issue. The problem is that until the hosting process for CryptSvc is cancelled, this routine actively prevents apps from opening at all, for example (but not limited to) MS Explorer from opening, menus from unfolding, Windows security pop-ups from operating, etc., SysInternals Process Explorer from running, CPUID's CPU-Z doing its thang, or even <Right Click> from functioning, etc., etc., - basically everything. NirSofer's "NirLauncher" app suite takes almost 5 minutes to run unless I kill the CryptSvc process, whereupon it loads instantly!
   Even the boot process is now incredibly slow ... but I cannot do anything about that until I have some control of the system!
   In short: the SvcHost processes hosting CryptSvc is killed otherwise I cannot do any meaningful work whatsoever, hence this forum post to attempt to resolve the underlying cause.
   No other Windows processes are killed.
   
   
5. One issue I am now facing is that the system is frequently running 'hot' - it is working over and above almost anything I have experienced in the past, one cause predominantly being CryptSvc and other MS security-related processes, e.g. MSMPEng, SecurityHealthService, MSCopyAccelerator, CompatTelRuner, et al.
   
   
6. Up until the aforementioned Win update was applied, I had an almost 100% stable system with almost zero app crashes and no BSOD episodes. There were no memory, CryptSvc or other issues - the system was more than fast enough and it was very stable.

To answer some of your specific questions / requests:-

1. Unfortunately, I have no idea which KB was applied.
   Having spent many days attempting to establish a usable system I could start working with again, the very last thing on my mind following this was to try and find out precisely what had been applied. Instead I was playing catch-up with my work, instead of playing at being a Windows tech. Sorry.
   There is now no apparent record of any Windows updates being applied that I can find, other than Windows Defender updates.
   
   
2. I deleted nothing from the SysnativeBSODCollectionApp reports I posted (and amended them in no way whatsoever) I merely updated exactly what was deposited on my desktop. I will upload the missing info separately for you in a future post later today if you can let me know specifically what you are missing / what you require.
   
   
3. Memory - That RAM has been in situ for almost 10 years without any problems whatsoever (that's not to say it might not have developed an issue more recently that just happens to coincide with the issues I am attempting to resolve here). However, as mentioned MemTest has revealed no problems.
   The 'missing' memory is PNY rated at PC3-12800 (800MHz) all with JEDEC #7: 11.0-11-11-28-39 @ 800 MHz.
   To be absolutely clear: My system was incredibly stable - it had to be! Some hefty music projects have been successfully run (extremely large, memory- and CPU-intensive multi-track projects) without issue. Your concern is noted but, perhaps, somewhat misplaced in this instance.
   
   
4. I will remove that RAM stick at some point and see whether that improves anything; however, I doubt it will have any impact whatsoever on the CryptSvc hosted process from preventing s/w from running - the actual issue I am attempting to resolve through the use of the failing SFC and DISM processes and this forum.
   
   
5. The only time I can run the SysnativeBSODCollectionApp is overnight, from around 02:00, as I am playing catch-up on late projects ... with a somewhat unstable system!
   Unfortunately, because of the BSOD, high system temperature issues I now have - not to mention the underlying CryptSvc issue - that last process took forever as well as several attempts to complete.
   On that basis (as per point 2 above), what other information was 'missing' from my original upload and I will run these reports individually, which should achieve the same overall result but be achieved much, much more quickly?

I hope this clarifies any questions, assumptions, presumptions and other issues you may have had with my previous post(s); please let me know if you require anything further and I'll do my very best to address them.

Kind regards,

Steve.

 

[ubuysa]

I don't think I'm going to be the right person to assist you. I'll step back and let one of the other analysts see whether they can assist.