[SOLVED] Critical Structure Corruption arg4:1c (Driver object corruption) + module unknown

C

CoinCoin

Windows Specialist
Joined
Jan 19, 2020
Posts
32
Hi,

I'm trying to find which driver is crashing the kernel on my system. I can't really find it because windbg tells me MODULE_NAME: Unknown_Module.

I really don't know from where comes this crash. I suspected my audio drivers and a curious IDE controler, which is unknown, keep trying to reinstall itself and fail with no drivers. I can't remove it, I have been trying around 40h failing that and I'm dry on ideas. Uninstalling it is making it come back with a new name with a normal boot.

The history of this machine is it's an old windows 7x64 machine, that I upgraded to win10x64 via an upgrade tool provided by microsoft. Drivers are up-to-date-ish (all should be ok but the videodriver installed post upgrade).

The BSOD happens randomly from 2 minutes to 1h. Record is today, I though I killed it, for 6h but it came back.
There is no BSOD if I start the computer in debug mode. In debug mode, the IDE controler isn't in the device manager.

For my background, I'm not an expert user. I consider myself a medium level user. I did electronics studies and am a software develloper.

Thanks for reading this thread, and please do tell if you would need more information.
 

Attachments

There doesn't appear to by any dump files in your zip folder, did you run any file cleaning tools like CCleaner recently? Could you please check the following directory and then zip up any dump files which may be there:

Code: 
%systemroot\Minidump

I would also suggest running MemTest for each RAM stick in each individual slot - Test RAM with PassMark MemTest86
 
Thanks for the answer.

Quick tests about ram using Windows Repair Tools were OK, but I can try that - I have less than 2 hour a day at home to test that, by 21:00 to 23:00 (on my timezone, it is 12:10 PM now).
The reason I did not investigate there is I wonder if a RAM issue would provoke that exact type of BSOD, and if I would never have experimented such BSOD during Win7 life of the computer, or in debug mode.

MiniDump files were left in my PC, because there was something like 20 of them. Exploitation of these through WhoCrash gave nothing. I set BSOD to generate kernel memory dumps, to analyse these with windbg. I will post minidump and the last memory dump tonigh, if the site permits that type of file.

My personnal suspect are :
- JMicron's chipset. It is desactivated in BIOS now, so driver shouldn't load. Device manger is clean from hidden devices, so it's not even remembered by windows. But there was a Win7 autorun name xInsIDE.exe. After desactivating it, the system was stable for 5 hours, which is an unique record. I suspect it to try to load IDE drivers for e-SATA ports on the front and back panels of the PC. I had to use advanced uninastaller pro to be able to find it - it isn't listed with windows tools.
I did that because of this IDE controler that keep coming back after each boot, because I suspect a driver try to instal or peek at a new IDE port that doesn't really exist (I suspect an external IDE drive).
- Sound card (A card that I read here that the official driver were not 1909 compatible)
- HyperX Cloud 2, that have issues with win10 that doesn't really work with 2 sound card computer : it have a deported sound card in the volume dongle).
- I have a lot of Wifi connect/disconnect issue that I did not investigate so far.

HyperX, Wifi, Mouse are on the front panel, and there is 1x e-SATA port on the front panel. The system crash even if reboot with no HyperX plugged there.

HyperX and JMicron drivers doesn't load in debug mode and debug mode is stable.

Other suspects :
- PEBCAK, because I tried lots of maintenance tools and actions, and I'm not a real specialist. I may have amplify an existing problem after a BSOD panic (not used to these in Win7).
- Maybe there was a rollback on a driver. I have to check why a driver upgrade tool detects it as obsolete.
 
Last edited:
CoinCoin said:
The reason I did not investigate there is I wonder if a RAM issue would provoke that exact type of BSOD, and if I would never have experimented such BSOD during Win7 life of the computer, or in debug mode.
Click to expand...

That bugcheck code is usually associated to RAM issues or HDD/SSD issues.

CoinCoin said:
MiniDump files were left in my PC, because there was something like 20 of them. Exploitation of these through WhoCrash gave nothing. I set BSOD to generate kernel memory dumps, to analyse these with windbg. I will post minidump and the last memory dump tonigh, if the site permits that type of file.
Click to expand...

Please zip those Minidump files and attach them to your next post. WhoCrashed isn't the best tool to use since it literally provides the bugcheck parameters and the "Probably caused by:" line. We all use WinDbg here to analyse dump files. With the Kernel Memory dump file, you'll need to zip it and then upload it to a file sharing site such as Dropbox, OneDrive or Google Drive. Please ensure that you post the link to the file in your next post.
 
Here's the minidumps.
The last memory dump is on Google Drive (link).

I'll memtest the ram and provide results but I need a large enough USB stick for that (-edit- found one, will do tonigth).
 

Attachments

Last edited:
1. Enable Driver Verifier Manager
2. Select "Create custom settings (for code developers)"
3. Tick all standard settings and 2 additional settings (force pending i/o request and irp logging)
4. Select "Select driver names from a list"
5. Tick all 3rd party drivers
6. Apply changes and reboot computer
 
Memtest this morning was 0 errors found after 3 pass on memtest 4.3. Still running. Will pass Driver Verifier after that first memtest.

I think a GPU ram test would be more relevant, because arg4 was 1c each time I checked (so, it's not random, so it's not an electrical issue with the ram, and can't be a logical issue since ram is "supposed to be" ECC - I may have botched the cofnig though : memtest 4.3 doesn't say it's ECC or not, but windows told it.).

GPU RAM acts behind a GPU driver. Last Nvidia video drivers were installed clean after a DDU uninstall. But those previous drivers were installed on Win7, and then DDU was launched through Win10.
Is there a GPU ram test somewhere ?

I still think it's that unknown IDE controler driver. It's not normal not to be able to remove it (it comes back on each reboot). It's not normal for it to be desactivated and still make traces in windows event log. (event id 10111 and 10110 : DCOM something, unauthorized driver install something).

I "would" try to shoot the registry with the GUID the device manager tells me this stuff is. Maybe it's an old hardware stuff from 2008 I forgot to uninstall and never make a problem for win7 (would say an external HDD).
The problem is my noobness in registry knowledge. I'm not sure it is such a really good idea.
 
Last edited:
FurMark is able to test the graphics card memory
 
Rich (BB code): 
3: kd> !drvobj ffffcc01e32288a0+0x60 f
Driver object (ffffcc01e3228900) is for:
\FileSystem\Ntfs

Driver Extension List: (id , addr)

Device Object list:
ffffcc01e3f11030  ffffcc01e3ec2030  ffffcc01e3e0d030  ffffcc01e3b17030
ffffcc01e35ce030  ffffcc01e322dde0

DriverEntry:   fffff8013c948010    Ntfs!GsDriverEntry
DriverStartIo: 00000000  
DriverUnload:  fffff8013c0997b8    sptd
AddDevice:     00000000  

Dispatch routines:
[00] IRP_MJ_CREATE                      fffff8013c7f7e00    Ntfs!NtfsFsdCreate
[01] IRP_MJ_CREATE_NAMED_PIPE           fffff8013951e8a0    nt!IopInvalidDeviceRequest
[02] IRP_MJ_CLOSE                       fffff8013c7f9a50    Ntfs!NtfsFsdClose
[03] IRP_MJ_READ                        fffff8013c6f6210    Ntfs!NtfsFsdRead
[04] IRP_MJ_WRITE                       fffff8013c6ec250    Ntfs!NtfsFsdWrite
[05] IRP_MJ_QUERY_INFORMATION           fffff8013c7f8a20    Ntfs!NtfsFsdDispatchWait
[06] IRP_MJ_SET_INFORMATION             fffff8013c7c3970    Ntfs!NtfsFsdSetInformation
[07] IRP_MJ_QUERY_EA                    fffff8013c7f8a20    Ntfs!NtfsFsdDispatchWait
[08] IRP_MJ_SET_EA                      fffff8013c7f8a20    Ntfs!NtfsFsdDispatchWait
[09] IRP_MJ_FLUSH_BUFFERS               fffff8013c822840    Ntfs!NtfsFsdFlushBuffers
[0a] IRP_MJ_QUERY_VOLUME_INFORMATION    fffff8013c81e550    Ntfs!NtfsFsdDispatch
[0b] IRP_MJ_SET_VOLUME_INFORMATION      fffff8013c81e550    Ntfs!NtfsFsdDispatch
[0c] IRP_MJ_DIRECTORY_CONTROL           fffff8013c7df960    Ntfs!NtfsFsdDirectoryControl
[0d] IRP_MJ_FILE_SYSTEM_CONTROL         fffff8013c80be00    Ntfs!NtfsFsdFileSystemControl
[0e] IRP_MJ_DEVICE_CONTROL              fffff8013c808020    Ntfs!NtfsFsdDeviceControl
[0f] IRP_MJ_INTERNAL_DEVICE_CONTROL     fffff8013951e8a0    nt!IopInvalidDeviceRequest
[10] IRP_MJ_SHUTDOWN                    fffff8013c909150    Ntfs!NtfsFsdShutdown
[11] IRP_MJ_LOCK_CONTROL                fffff8013c7286b0    Ntfs!NtfsFsdLockControl
[12] IRP_MJ_CLEANUP                     fffff8013c7fa9f0    Ntfs!NtfsFsdCleanup
[13] IRP_MJ_CREATE_MAILSLOT             fffff8013951e8a0    nt!IopInvalidDeviceRequest
[14] IRP_MJ_QUERY_SECURITY              fffff8013c81e550    Ntfs!NtfsFsdDispatch
[15] IRP_MJ_SET_SECURITY                fffff8013c81e550    Ntfs!NtfsFsdDispatch
[16] IRP_MJ_POWER                       fffff8013951e8a0    nt!IopInvalidDeviceRequest
[17] IRP_MJ_SYSTEM_CONTROL              fffff8013951e8a0    nt!IopInvalidDeviceRequest
[18] IRP_MJ_DEVICE_CHANGE               fffff8013951e8a0    nt!IopInvalidDeviceRequest
[19] IRP_MJ_QUERY_QUOTA                 fffff8013c7f8a20    Ntfs!NtfsFsdDispatchWait
[1a] IRP_MJ_SET_QUOTA                   fffff8013c7f8a20    Ntfs!NtfsFsdDispatchWait
[1b] IRP_MJ_PNP                         fffff8013c854890    Ntfs!NtfsFsdPnp

Fast I/O routines:
FastIoCheckIfPossible                   fffff8013c8edf30    Ntfs!NtfsFastIoCheckIfPossible
FastIoRead                              fffff8013c7fa3a0    Ntfs!NtfsCopyReadA
FastIoWrite                             fffff8013c7c8e20    Ntfs!NtfsCopyWriteA
FastIoQueryBasicInfo                    fffff8013c81b640    Ntfs!NtfsFastQueryBasicInfo
FastIoQueryStandardInfo                 fffff8013c819760    Ntfs!NtfsFastQueryStdInfo
FastIoLock                              fffff8013c81d1d0    Ntfs!NtfsFastLock
FastIoUnlockSingle                      fffff8013c81dbb0    Ntfs!NtfsFastUnlockSingle
FastIoUnlockAll                         fffff8013c8ed210    Ntfs!NtfsFastUnlockAll
FastIoUnlockAllByKey                    fffff8013c8ed4d0    Ntfs!NtfsFastUnlockAllByKey
ReleaseFileForNtCreateSection           fffff8013c704650    Ntfs!NtfsReleaseForCreateSection
FastIoQueryNetworkOpenInfo              fffff8013c81b220    Ntfs!NtfsFastQueryNetworkOpenInfo
AcquireForModWrite                      fffff8013c6fb450    Ntfs!NtfsAcquireFileForModWrite
MdlRead                                 fffff8013c808d10    Ntfs!NtfsMdlReadA
MdlReadComplete                         fffff801394fa360    nt!FsRtlMdlReadCompleteDev
PrepareMdlWrite                         fffff8013c807de0    Ntfs!NtfsPrepareMdlWriteA
MdlWriteComplete                        fffff80139aabf10    nt!FsRtlMdlWriteCompleteDev
FastIoQueryOpen                         ffffcc01e3007540    +0xffffcc01e3007540 << Modified entry
ReleaseForModWrite                      fffff8013c705150    Ntfs!NtfsReleaseFileForModWrite
AcquireForCcFlush                       fffff8013c6fd0e0    Ntfs!NtfsAcquireFileForCcFlush
ReleaseForCcFlush                       fffff8013c7050c0    Ntfs!NtfsReleaseFileForCcFlush


Rich (BB code): 
3: kd> u 0xffffcc01e3007540
ffffcc01`e3007540 4d8bc8          mov     r9,r8
ffffcc01`e3007543 4c8bc2          mov     r8,rdx
ffffcc01`e3007546 488bd1          mov     rdx,rcx
ffffcc01`e3007549 48b9007000e301ccffff mov rcx,0FFFFCC01E3007000h
ffffcc01`e3007553 48b8dc270d3c01f8ffff mov rax,offset sptd+0x627dc (fffff801`3c0d27dc)
ffffcc01`e300755d ffe0            jmp     rax
ffffcc01`e300755f 004d8b          add     byte ptr [rbp-75h],cl
ffffcc01`e3007562 c84c8bc2        enter   8B4Ch,0C2h

Rich (BB code): 
3: kd> lmvm sptd
Browse full module list
start             end                 module name
fffff801`3c070000 fffff801`3c196000   sptd       (no symbols)         
    Loaded symbol image file: sptd.sys
    Image path: \SystemRoot\System32\Drivers\sptd.sys
    Image name: sptd.sys
    Browse all global symbols  functions  data
    Timestamp:        Sun Oct 11 21:55:14 2009 (4AD24632)
    CheckSum:         000D6B26
    ImageSize:        00126000
    File version:     1.62.0.0
    Product version:  1.62.0.0
    File flags:       8 (Mask 3F) Private
    File OS:          40004 NT Win32
    File type:        3.7 Driver
    File date:        00000000.00000000
    Translations:     0000.04b0
    Information from resource tables:
        CompanyName:      Duplex Secure Ltd.
        ProductName:      SCSI Pass Through Direct
        InternalName:     SPTD.SYS
        OriginalFilename: sptd.sys
        ProductVersion:   1.62.0.0
        FileVersion:      1.62.0.0 built by: WinDDK
        FileDescription:  SCSI Pass Through Direct Host
        LegalCopyright:   Copyright (C) 2004



Looks like the IRP handlers table has been modified, the culprit appears to Daemon tools which is known to cause issues with Windows machines. Please remove the driver using the following removal tool:


DuplexSecure - Downloads
 
Last edited:
Wow. I somehow "knew" it was a virtual device, I tried to remove everything that was virtual drive and I though it killed everything.
If you really found the culprit, I owe you big thanks because I really was stuck.

Was going there just to say memtest was ok after 8 pass.

-edit- The uninstaller doesn't work because that driver is old + win7 and the new one doesn't enable the button "uninstall" (it may detect only its version + win10). I'll try disabling it through the register for first stability tests.
 
Last edited:
Cool.

I installed the win10 version, reboot, then uninstall the win10 version, then reboot.

So far, my biggest concern was that unknown IDE controler in device manager, and this alone made it gone. Clicked on show hidden device, and kicked it from there too.

Then reboot, and no more unknown IDE controler, no more hidden device.

In registry, this made a key called HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\sptd2 key, with the wanted "disabled" value adviced by DuplexSecure.

The sptd.sys driver is still in C:\Windows\System32\drivers though.
spdt isn't running in the taskmanager and sptd*.sys couldn't be found elsewhere on the computer. It's only present in the current driver folder.

=> So I wonder if it's safe to delete it. This should highligth the daddy driver that calls for spdt with errors in event log, no ?

Oh, and so far, in one hour, no BSOD. Will let it run 24h to check. This is neat, this made me curious on how to track bugs in kernels now because that one really was outside of my knowledge - I (should) know most from sand to before-the-kernel drivers (y2k electronics tech), then some from software but kernels & after-the-kernel drivers were always a mysteryto me :)
 
CoinCoin said:
In registry, this made a key called HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\sptd2 key, with the wanted "disabled" value adviced by DuplexSecure.

The sptd.sys driver is still in C:\Windows\System32\drivers though.
spdt isn't running in the taskmanager and sptd*.sys couldn't be found elsewhere on the computer. It's only present in the current driver folder.

=> So I wonder if it's safe to delete it. This should highligth the daddy driver that calls for spdt with errors in event log, no ?
Click to expand...

You could create a System Restore point and then renaming the driver to sptd.old, but disabling within the registry will be enough.

CoinCoin said:
This is neat, this made me curious on how to track bugs in kernels now because that one really was outside of my knowledge - I (should) know most from sand to before-the-kernel drivers (y2k electronics tech), then some from software but kernels & after-the-kernel drivers were always a mysteryto me :)
Click to expand...

If you're interested in learning crash dump debugging, then we have an academy - Sysnative BSOD Academy
 
So, no BSOD after +/-20h. You can mark as solved, the remaining problems are maintenance stuff I should easilly find a solution for. I owe you big thanks, I was struggling over this for around one month now.

Regarding the Academy, I'd prefer this to be casual (because I realize by reading the questionnary, I could be quite disapointing). But I'll learn anyway :)
 
Back
Top