SC2 True Drive 2024.5 Causing Reboots? [Update: No]

I upgraded a few weeks ago to 2024.5 (not plus). Since then, I have been experiencing crashes under the following conditions:
PC Powered off for a while
Power On, Load into an iRacing session
after ~5mins, PC screen goes black and reboot begins.
(after the crash reboot, i can use the PC normally without issue until next power down)

MS events:
The computer has rebooted from a bugcheck. The bugcheck was: 0x0000007f (0x0000000000000008, 0xfffff8037e4bae70, 0xfffff5023d960f00, 0xfffff803802546d9).

Crash dump log:
CUSTOMER_CRASH_COUNT: 1

PROCESS_NAME: Simucube 2 Tru

STACK_TEXT:
fffff5023d960f00 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiDeferredReadySingleThread+0x39

SYMBOL_NAME: nt!KiDeferredReadySingleThread+39

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

IMAGE_VERSION: 10.0.22621.3733

STACK_COMMAND: .cxr; .ecxr ; kb

BUCKET_ID_FUNC_OFFSET: 39

FAILURE_BUCKET_ID: 0x7f_8_STACKPTR_ERROR_nt!KiDeferredReadySingleThread

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {5caea26b-f97b-09d4-475a-719857c26295}

For what it’s worth, I am on windows 11, not 10. I doubt that’s the issue, though.

If I boot do the same crash scenario using AM2 or ACC, no crash. It only crashes with iRacing. I am using the 360hz FFB mode. I don’t know if this is the cause.

Full log below:


  •                                                                         *
    
  •                    Bugcheck Analysis                                    *
    
  •                                                                         *
    

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it’s a trap of a kind
that the kernel isn’t allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
BugCheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a portion of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: fffff8037e4bae70
Arg3: fffff5023d960f00
Arg4: fffff803802546d9

Debugging Details:

KEY_VALUES_STRING: 1

Key  : Analysis.CPU.mSec
Value: 78

Key  : Analysis.Elapsed.mSec
Value: 1544

Key  : Analysis.IO.Other.Mb
Value: 15

Key  : Analysis.IO.Read.Mb
Value: 0

Key  : Analysis.IO.Write.Mb
Value: 31

Key  : Analysis.Init.CPU.mSec
Value: 15

Key  : Analysis.Init.Elapsed.mSec
Value: 38383

Key  : Analysis.Memory.CommitPeak.Mb
Value: 97

Key  : Bugcheck.Code.LegacyAPI
Value: 0x1000007f

Key  : Bugcheck.Code.TargetModel
Value: 0x1000007f

Key  : Dump.Attributes.AsUlong
Value: 1808

Key  : Dump.Attributes.DiagDataWrittenToHeader
Value: 1

Key  : Dump.Attributes.ErrorCode
Value: 0

Key  : Dump.Attributes.KernelGeneratedTriageDump
Value: 1

Key  : Dump.Attributes.LastLine
Value: Dump completed successfully.

Key  : Dump.Attributes.ProgressPercentage
Value: 0

Key  : Failure.Bucket
Value: 0x7f_8_STACKPTR_ERROR_nt!KiDeferredReadySingleThread

Key  : Failure.Hash
Value: {5caea26b-f97b-09d4-475a-719857c26295}

Key  : Hypervisor.Enlightenments.ValueHex
Value: 1417df84

Key  : Hypervisor.Flags.AnyHypervisorPresent
Value: 1

Key  : Hypervisor.Flags.ApicEnlightened
Value: 0

Key  : Hypervisor.Flags.ApicVirtualizationAvailable
Value: 1

Key  : Hypervisor.Flags.AsyncMemoryHint
Value: 0

Key  : Hypervisor.Flags.CoreSchedulerRequested
Value: 0

Key  : Hypervisor.Flags.CpuManager
Value: 1

Key  : Hypervisor.Flags.DeprecateAutoEoi
Value: 1

Key  : Hypervisor.Flags.DynamicCpuDisabled
Value: 1

Key  : Hypervisor.Flags.Epf
Value: 0

Key  : Hypervisor.Flags.ExtendedProcessorMasks
Value: 1

Key  : Hypervisor.Flags.HardwareMbecAvailable
Value: 1

Key  : Hypervisor.Flags.MaxBankNumber
Value: 0

Key  : Hypervisor.Flags.MemoryZeroingControl
Value: 0

Key  : Hypervisor.Flags.NoExtendedRangeFlush
Value: 0

Key  : Hypervisor.Flags.NoNonArchCoreSharing
Value: 1

Key  : Hypervisor.Flags.Phase0InitDone
Value: 1

Key  : Hypervisor.Flags.PowerSchedulerQos
Value: 0

Key  : Hypervisor.Flags.RootScheduler
Value: 0

Key  : Hypervisor.Flags.SynicAvailable
Value: 1

Key  : Hypervisor.Flags.UseQpcBias
Value: 0

Key  : Hypervisor.Flags.Value
Value: 21631230

Key  : Hypervisor.Flags.ValueHex
Value: 14a10fe

Key  : Hypervisor.Flags.VpAssistPage
Value: 1

Key  : Hypervisor.Flags.VsmAvailable
Value: 1

Key  : Hypervisor.RootFlags.AccessStats
Value: 1

Key  : Hypervisor.RootFlags.CrashdumpEnlightened
Value: 1

Key  : Hypervisor.RootFlags.CreateVirtualProcessor
Value: 1

Key  : Hypervisor.RootFlags.DisableHyperthreading
Value: 0

Key  : Hypervisor.RootFlags.HostTimelineSync
Value: 1

Key  : Hypervisor.RootFlags.HypervisorDebuggingEnabled
Value: 0

Key  : Hypervisor.RootFlags.IsHyperV
Value: 1

Key  : Hypervisor.RootFlags.LivedumpEnlightened
Value: 1

Key  : Hypervisor.RootFlags.MapDeviceInterrupt
Value: 1

Key  : Hypervisor.RootFlags.MceEnlightened
Value: 1

Key  : Hypervisor.RootFlags.Nested
Value: 0

Key  : Hypervisor.RootFlags.StartLogicalProcessor
Value: 1

Key  : Hypervisor.RootFlags.Value
Value: 1015

Key  : Hypervisor.RootFlags.ValueHex
Value: 3f7

BUGCHECK_CODE: 7f

BUGCHECK_P1: 8

BUGCHECK_P2: fffff8037e4bae70

BUGCHECK_P3: fffff5023d960f00

BUGCHECK_P4: fffff803802546d9

FILE_IN_CAB: 062524-14890-01.dmp

TAG_NOT_DEFINED_202b: *** Unknown TAG in analysis list 202b

DUMP_FILE_ATTRIBUTES: 0x1808
Kernel Generated Triage Dump

BAD_STACK_POINTER: fffff5023d960f00

BLACKBOXBSD: 1 (!blackboxbsd)

BLACKBOXNTFS: 1 (!blackboxntfs)

BLACKBOXPNP: 1 (!blackboxpnp)

BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT: 1

PROCESS_NAME: Simucube 2 Tru

STACK_TEXT:
fffff5023d960f00 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiDeferredReadySingleThread+0x39

SYMBOL_NAME: nt!KiDeferredReadySingleThread+39

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

IMAGE_VERSION: 10.0.22621.3733

STACK_COMMAND: .cxr; .ecxr ; kb

BUCKET_ID_FUNC_OFFSET: 39

FAILURE_BUCKET_ID: 0x7f_8_STACKPTR_ERROR_nt!KiDeferredReadySingleThread

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {5caea26b-f97b-09d4-475a-719857c26295}

Followup: MachineOwner

Can you test if it works any differently if you disable the 360 Hz mode?

Going to do a bit of a play by play in case you’re watching. Before I did hte test, I confirmed that if i do a normal “shut down” operation, I can force the crash to occur. I confirmed, I could.

Now I just disabled 3 settings in the app.ini.
I disabled simagic API, simucubeAPI, and 360hzintropolated.

I hope those 3 settings are what you’re after for “disabling” 360. I am now going to do a full reboot and load into a session to see if it crashes with it disabled. Be back in ~15-20mins.

TLDR; still crashing. The .dmp files keep changing what they’re blaming for crashes. Even the .dmp file from yesterday that I used to generate this post is also reporting a different crash source when I run --analyze, which leads me to believe the .dmp file information I’m sharing is unreliable.

I would like to know if you are aware of any risks in me downgrading from 2024.5 to 2024.4 other than just losing profile info. SC was the only software update I did before experiencing these bugs, so I’d like to test that before I begin speculating about hardware malfunctions.

I’m also willing to send the individual .dmp files. All the files I have were generated from the scenario I’m describing. I’ve not had a crash otherwise.

Test information below, for your visibility:

Ok, I booted up, loaded an iRacing session, confirmed SC2 software did NOT display the info screen info for 360 enabled.

I crashed, same as with it enabled.

The computer has rebooted from a bugcheck. The bugcheck was: 0x0000007f (0x0000000000000008, 0xffffb880b1d7ee70, 0xffff9484efe28fc0, 0xfffff8077f2a1f2e). A dump was saved in: C:\Windows\Minidumps

so the non-360 dump file pointed to anticheat, not SC2:
SYMBOL_NAME: EasyAntiCheat_EOS+10ac301
MODULE_NAME: EasyAntiCheat_EOS
IMAGE_NAME: EasyAntiCheat_EOS.sys
STACK_COMMAND: .cxr; .ecxr ; kb
BUCKET_ID_FUNC_OFFSET: 10ac301
FAILURE_BUCKET_ID: 0x7f_8_EasyAntiCheat_EOS!unknown_function
OSPLATFORM_TYPE: x64
OSNAME: Windows 10

FAILURE_ID_HASH: {9d5b0e91-8976-ce0a-e55f-fa940c7a1997}

The crash I had prior with 360-enabled:
SYMBOL_NAME: EasyAntiCheat_EOS+7954d0
MODULE_NAME: EasyAntiCheat_EOS
IMAGE_NAME: EasyAntiCheat_EOS.sys
STACK_COMMAND: .cxr; .ecxr ; kb
BUCKET_ID_FUNC_OFFSET: 7954d0
FAILURE_BUCKET_ID: 0x7f_8_EasyAntiCheat_EOS!unknown_function

The first crash of the day I had with 360 enabled (overnight start up):
SYMBOL_NAME: nt!KiHeteroScanQueueForPreemptionSwapTarget+7b
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
IMAGE_VERSION: 10.0.22621.3733
STACK_COMMAND: .cxr; .ecxr ; kb
BUCKET_ID_FUNC_OFFSET: 7b
FAILURE_BUCKET_ID: 0x7f_8_STACKPTR_ERROR_nt!KiHeteroScanQueueForPreemptionSwapTarget

I am now downgrading to 2024.3.

Crash occurred on 2024.3, which is definitely making me think this is less likely to be a SC issue.

Odd timing… a windows update just showed up, I installed it. Since the windows update, I had 1 session that froze (not crashed) which was a first… then I rebooted, shut down and started up again to reset the test and this instance, I ran clean for 20mins, which is a first. I just shut down to force a new test and I’ve just done another 20mins without crashing.

Fingers crossed, maybe that windows update fixed something for me.

Yeah, sounds a lot like an issue with either windows update or some component on your PC possibly going bad.