BSOD volmgr 162

Well after over a month of troubleshooting it led me to the hard drive and after changing the SATA cable (and pluging it into a different socket) the PC seems to be working fine. What I've gathered from the repair shop (which wasn't otherwise very helpful) is that the hard drive sometimes slowed down while sending data which might have caused the ram to loop and bsod, so I guess if someone else falls into this hell-hole of a problem, check your cables!

That event trace does not indicate the underlying cause of the crashes.

Please check to see if your PC is producing any minidump files, I will check those to see if they provide any insight into a potential cause of the system crashes.

Please do not upload a very large Memory.dmp file.

Open Windows File Explorer.

Navigate to C:\Windows\Minidump

Copy any minidump files onto your Desktop, then zip those up.

Upload the zip file to the Cloud (OneDrive... etc.), then choose to share those and get a share link.

Then post the link here to the zip file, so I can take a look for you.

Event ID 162 from volmgr together with Kernel-Power 41 and frequent BSODs strongly indicates an underlying hardware/storage path problem rather than a Windows file corruption issue, especially since SFC/DISM and memory tests have already been run multiple times.

Given the context, the most likely causes are:

1. Intermittent or failing storage hardware (SSD or its controller)
2. Motherboard/storage controller issues (NVMe/PCIe, SATA, chipset)
3. Power delivery instability affecting the drive

Because volmgr is the volume manager, an Event 162 on different HarddiskVolumeX values (sometimes the SSD, sometimes the USB stick) means the system is losing access to a volume at a low level, which can cause crashes before Windows can log a proper bugcheck.

Recommended next steps, in order:

1. Treat this as a hardware/storage issue
   • The long, repeated corruption scenarios and unexplained BSODs described in the context were ultimately traced to a drive-side SRAM/controller fault, not Windows itself.
   • Even when software tools (SFC, DISM, vendor diagnostics) reported the disk as healthy, the root cause was still a defective SSD/controller.
2. Isolate the primary system drive
   • If possible, temporarily install Windows on a different physical SSD/HDD (even a small spare drive) and run the system for a while under similar usage.
   • If the crashes disappear on the alternate drive, this strongly implicates the original SSD or its controller.
3. Minimize variables on the current system
   • Disconnect all non-essential drives and USB storage devices and test with only:
     • System drive
     • Keyboard/mouse
     • Monitor
   • This helps confirm whether the volmgr 162 events are tied specifically to the system SSD or to other attached storage.
4. Check for overclocking and stability
   • Ensure CPU, RAM, and GPU are all at stock settings in BIOS/UEFI.
   • Disable any vendor overclocking/“performance tuning” utilities. In a similar case, uninstalling an OEM tuning tool (that was dynamically changing CPU frequencies) resolved repeated BSODs that looked like hardware faults.
5. Run extended vendor diagnostics on the SSD
   • Use the SSD manufacturer’s own diagnostic tool and run the most thorough/extended test available.
   • If any SMART attributes or tests fail, or if the tool reports internal memory/controller errors, replace the SSD.
6. Consider motherboard / controller issues
   • If a different SSD shows the same pattern of volmgr 162 and random BSODs, suspect:
     • NVMe slot or PCIe lane issues
     • Chipset or storage controller problems
     • Power delivery on the board (VRM, capacitors)
   • In that case, testing the suspect SSD in another PC (if available) can help distinguish between drive vs. board.
7. If you can capture a dump, analyze for hardware corruption
   • When a dump is available, bug checks like FAULTY_HARDWARE_CORRUPTED_PAGE (0x12B) or CRITICAL_STRUCTURE_CORRUPTION (0x109) are classic signatures of physical memory or device/driver corrupting memory.
   • For 0x12B, the official guidance is to run Windows Memory Diagnostics and investigate defective RAM or devices doing bad DMA.
   • For 0x109, check Event Viewer for drivers implicated around the time of the crash, and run memory and hardware diagnostics.
8. If repeated corruption persists across clean installs
   • Multiple clean installs, recurring component store (WinSxS) corruption, and disappearing updates after apparently successful installs are a strong indicator of underlying hardware failure.
   • In a documented case with similar symptoms (repeated WinSxS corruption, inexplicable BSODs, and update failures), the root cause was a defective SSD with an internal SRAM/controller error. Replacing the SSD resolved the issue.

Given the pattern of volmgr 162 on different volumes and the extensive software troubleshooting already done, the most pragmatic path is:

• Prioritize testing with a different system drive.
• If that stabilizes the system, replace the current SSD.
• If not, escalate suspicion to the motherboard/storage controller and consider board-level diagnostics or replacement.

References:

• Advanced troubleshooting for Event ID 41: "The system has rebooted without cleanly shutting down first"
• Bug check 0x12B: FAULTY_HARDWARE_CORRUPTED_PAGE
• Bug Check 0x109: CRITICAL_STRUCTURE_CORRUPTION
• WinSxS Corruptions Despite Numerous Formats to Windows, Silent Corruption and Deletion of Windows Update Files - Microsoft Q&A
• Please check my minidumps, BSOD and shutdowns - Microsoft Q&A