Question BSOD - Stop Code: Critical_structure_corruption CI.dll ?

[Umit22]

i5 10400F
B460M-A PRO (MS -7C88)
GTX 2070
G.Skill Ripjaws V 32 GB (2x16) 3600 MHz DDR4 CL18 ( Already changed RAMs for test BSOD so problem wont be on RAMS)
James Donkey JD480 480GB

did almost all scans for Disk its looks good too.

any help would be great.
==================================================
Dump File : 092323-18859-01.dmp
Crash Time : 23.09.2023 21:04:04
Bug Check String :
Bug Check Code : 0x00000109
Parameter 1 : a39fbfdc`6dff2c15
Parameter 2 : b3b6cc62`c0817409
Parameter 3 : fffff803`3bc293f8
Parameter 4 : 00000000`00000000
Caused By Driver : CI.dll
Caused By Address : CI.dll+393f8
File Description :
Product Name :
Company :
File Version :
Processor : x64
Crash Address : ntoskrnl.exe+3fcd70
Stack Address 1 :
Stack Address 2 :
Stack Address 3 :
Computer Name :
Full Path : C:\Windows\Minidumps\092323-18859-01.dmp
Processors Count : 12
Major Version : 15
Minor Version : 19041
Dump File Size : 593.005
Dump File Time : 23.09.2023 21:04:41
==================================================

---here dumps---

DUMP – Google Drive

drive.google.com

 

[Umit22]

Hi

Does the system boot to the desktop? If so my suggestion is install updates for all drivers meaning for

motherboard bios The latest one is 7C88v19
Intel chipset
On board graphics ( even if you have a gpu)
Sound driver
Lan driver

Drivers link

B460M-A PRO

Inspired from architectural design with the Core Boost, DDR4 Boost, Audio Boost, Turbo M.2 with M.2 Shield Frozr

www.msi.com

See how this helps

No just re-starting windows.

Also all drivers updated yesterday but i got BSOD again after update too

 

[ubuysa]

Well, despite you changing RAM sticks these identical dumps all point at a RAM issue...

FAILURE_BUCKET_ID:  MEMORY_CORRUPTION_ONE_BIT

One other similarity is that they all fail in the CI.dll module, this is a component of Windows Code Integrity, so it's not impossible that a rouge driver is corrupting a data structure that CI.dll uses. The only way to find a potentially rogue third-party driver is to enable Driver Verifier.

Bad RAM is still the most likely cause here, so you need to be 100% certain that both sets of RAM that you've used are matched sets (same part numbers in each set) and that both sets are ideally on the QVL for your motherboard. I would advise trying with just one stick of RAM to see whether it still BSODs (and try different single sticks too).

If you want to enable Driver Verifier here's how to do that and the options to use...

1. Take a System Restore point and/or take a disk image of your system drive (with Acronis, Macrium Reflect, or similar). It is possible that Driver Verifier may BSOD a driver during the boot process (some drivers are loaded during boot). If that happens you'll be stuck in a boot-BSOD loop.

If you should end up in a boot-BSOD loop, boot the Windows installation media and use that to run system restore and restore to the restore point you took, to remove Driver Verifier and get you booting again. Alternatively you can use the Acronis, Macrium Reflect, or similar, boot media to restore the disk image you took.

Please don't skip this step. it's the only way out of a Driver Verifier boot-BSOD loop.

2. Start the Driver Verifier setup dialog by entering the command verifier in either the Run command box or in a command prompt.

3. On the initial dialog, click the radio button for 'Create custom settings (for code developers)' - the second option - and click the Next button.

4. On the second dialog check (click) the checkboxes for the following tests...

• Special Pool
• Force IRQL checking
• Pool Tracking
• Deadlock Detection
• Security Checks
• Miscellaneous Checks
• Power framework delay fuzzing
• DDI compliance checking

Then click the Next button.

5. On the next dialog click the radio button for 'Select driver names from a list' - the last option - and click the Next button.

6. On the next dialog click on the 'Provider' heading, this will sort the drivers on this column (it makes it easier to isolate Microsoft drivers).

7. Now check (click) ALL drivers that DO NOT have Microsoft as the provider (ie. check all third-party drivers).

8. Then, on the same dialog, check the following Microsoft drivers (and ONLY these Microsoft drivers)...

• Wdf01000.sys
• ndis.sys
• fltMgr.sys
• Storport.sys

These are Microsoft high-level drivers that call third-party drivers that we wouldn't otherwise see, that's why these Microsoft drivers are selected.

9. Now click Finish and then reboot. Driver Verifiier will be enabled.

Be aware that Driver Verifier will remain enabled across all reboots and shutdowns. It can only be disabled manually.

Also be aware that we expect BSODs. Indeed, we want BSODs, to be able to identify the flaky driver(s). You MUST keep all minidumps created whilst Driver Verifier is running, so disable any disk cleanup tools you may have.

10. Leave Driver Verifier running until you've had between 5 and 10 BSODs, or for 48 hours. Use your PC as normal during this time, but do try and make it BSOD. Use every game or app that you normally use, and especially those where you have seen it BSOD in the past.

11. To turn Driver Verifier off enter the command verifier /reset in either Run command box or a command prompt and reboot.

Should you wish to check whether Driver Verfier is enabled or not, open a command prompt and enter the command verifier /query. If drivers are listed then it's enabled, if no drivers are listed then it's not.

12. When Driver Verifier has been disabled, navigate to the folder C:\Windows\Minidump and locate all .dmp files in there that are related to the period when Driver Verifier was running (check the timestamps). Upload all those dumps to a cloud service with a link to them here (be sure to make them public).