bugcheck BSOD Windows crash

[albinoni]

I got a BSOD crash on win 11 pro tonight at the exact instant that I hit the compare button in freefilesync. There is a bugcheck event in event viewer and the memory.dmp file is 2.8 GB. Do you want me to upload it somewhere?

I have a brand new PC I7 14700K - the variety that was susceptible to Intel's over-voltage problem or whatever it was - but it's very unlikely that is the problem as it is brand new. I started getting daily crashes/ spurious reboots a couple of weeks ago so after a few days I disconnected an external 4TB seagate HDD with hardware encryption but still got a crash so uninstalled Macrium Reflect and had no more crashes until today when I reconnected the seagate HDD. Today's crash was a genuine blue screen, of the previous crashes I only witnessed a couple and there was no blue screen, (just a black screen restart) and nothing in the event viewer to indicate the cause. This morning I reconnected the seagate HDD so I strongly suspect the crash is connected with that, however my freefilesync config is not set up to access the seagate - however it does access a samsung USB SSD drive. I also have realtimesync running but not accessing the seagate drive.

Windows event viewer reports some errors for "bitlocker driver" in relation to the seagate drive - timeouts - however, bitlocker is turned off for all drives.

bugcheck info is
param1 0x0000012c (0x00000000001c08c5, 0x0000000000000000, 0x0000000000000000, 0x000000000000000

Has anyone ever reported a BSOD associated with freefilesync?

EventData
BugcheckCode 300
BugcheckParameter1 0x1c08c5
BugcheckParameter2 0x0
BugcheckParameter3 0x0
BugcheckParameter4 0x0
SleepInProgress 0
PowerButtonTimestamp 0
BootAppStatus 0
Checkpoint 16
ConnectedStandbyInProgress false
SystemSleepTransitionsToOn 2
CsEntryScenarioInstanceId 13
BugcheckInfoFromEFI false
CheckpointStatus 0
CsEntryScenarioInstanceIdV2 13
LongPowerButtonPressDetected false
LidReliability false
InputSuppressionState 0
PowerButtonSuppressionState 0
LidState 3

[xCSxXenon]

This sounds like the quintessential bad/failing CPU behavior. Erroneous and 'all over the place' crashes like these have been the consistent pattern that leads us to replace CPUs in my shop. Update your BIOS to the latest available. Make sure the BIOS release notes show that the Intel Microcode will be updated to 0x129. If you complete that update and still have issues, I would bet throwing a different CPU in will change everything.

[albinoni]

Updating the BIOS and drivers was one of the first things that I did a couple of weeks ago. I doubt if Intel would agree to replace the CPU on this history and I have to trust the shop who built the PC that they fitted a brand new CPU. I suspect it's something to do with the hardware encrypting seagate drive and hitting compare in freefilesync somehow triggered the problem. I did partition the seagate USB HDD drive, which is probably not very common so I think I will reformat back to one drive and see what happens.

[xCSxXenon]

Intel extended their warranty periods for the affected CPUs, and 14th gen is in warranty even without the extension. It being "brand-new" doesn't matter either. A brand new car can explode 50 ft off the lot if there is a fault in the programming. If this was a computer I was working on, I would throw a known-good CPU in and perform the same tests

[Zenju]

See: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/blue-screen-data

0x12c = EXFAT_FILE_SYSTEM
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x12c---exfat-file-system

[albinoni]

exfat - that is my Samsung USB drive !!! - the seagate is NTFS. Wow, thankyou. FreeFileSync was trying to read the samsung drive when I got the blue screen.

On that web page you linked to, microsoft says this bugcheck does not indicate a problem with the filesystem on the drive but rather that Windows has got lost and is rebooting before the file system is damaged by the "unstable" OS. Freefilesync logs show that the content of the USB drive was identical before and after the crash so no data was lost.

I have "copy locked files" enabled. I'm also getting warnings in the FFS log that it couldn't copy from the USB drive to the recycle bin - the folder in question is tmp.driveupload on the usb drive. I guess FFS creates that on the usb drive for some reason and can't copy it because it is encrypted. Be nice to be able to turn off the copy to the recycle bin. If tmp.driveupload is actually created by FFS it should try to bypass the recycle bin for that folder.

I think all the crashes have been when I had the seagate usb drive connected so I'm gonna disconnect again and hope for no more crashes. Except for the one blue screen crash, I think all the instant reboot crashes happened when there was actually no reading or writing of the USB drive happening. I don't feel like pressing for a CPU swap without trying harder to eliminate a software cause, nor do I want to be without the machine for the time it would take the shop to investigate it.

Thanks a lot for looking up the error code.

[Zenju]

I'd suggest loading the "memory.dmp" in WinDbg and clicking on the "!analyze" link. This will generate a basic overview of what was happening during the crash, including a small call stack, which could give some more clues.

[albinoni]

Thanks for the suggestion. I was just about to install windbg when windows decided to crash/ restart for no obvious reason.
So the hardware encrypting one-touch seagate drive has now been disconnected, probably my crashes will stop too.

After running windbg and clicking the analysis link it shows the process was indeed FreeFileSync_x64.exe and module was exfat. The stack makes no sense to me

here's a OneDrive link to the windbg analysis
https://1drv.ms/t/s!AuLTu8TbQHbtggeae8qgVm8IUkDX?e=2SUPVv

here's a little bit of the stack

PROCESS_NAME: FreeFileSync_x64.exe

STACK_TEXT:
ffffcb82`98bdb988 fffff807`5394c85c : 00000000`0000012c 00000000`001c08c5 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
ffffcb82`98bdb990 fffff807`5396032c : 00000000`00000001 ffffcb82`98bdd950 00000000`00033bee ffffbb86`9e163e10 : exfat!FppDeleteFcb+0x44
ffffcb82`98bdb9d0 fffff807`1c1d2321 : ffffcb82`00000002 ffffcb82`98bdd950 ffffcb82`98bd7000 ffffcb82`98bde000 : exfat!FppCreateNewFile$fin$7+0x1ba
ffffcb82`98bdba60 fffff807`1c22171f : 00000000`00000002 ffffcb82`98bdc060 ffffcb82`98bddf30 ffffcb82`98bdbb60 : nt!_C_specific_handler+0x191
ffffcb82`98bdbad0 fffff807`1c080cb8 : 00000000`00000000 ffffcb82`98bddf30 fffff807`53935063 fffff807`53925f78 : nt!RtlpExecuteHandlerForUnwind+0xf

...

ffffcb82`9621f590 fffff807`1c4e8162 : ffffbb86`79f11001 ffffcb82`9621f7b0 00000000`00000040 ffffbb86`65bfeae0 : nt!ObpLookupObjectName+0x7e1
ffffcb82`9621f720 fffff807`1c5cf0b7 : 000001d7`00000000 ffffbb86`82d21a20 00000050`7c6fd680 00000000`00000001 : nt!ObOpenObjectByNameEx+0x1f2
ffffcb82`9621f850 fffff807`1c5ce589 : 00000050`7c6fd620 000001d7`c0110080 00000050`7c6fd680 00000050`7c6fd628 : nt!IopCreateFile+0xb17
ffffcb82`9621f920 fffff807`1c22b605 : 00007ff6`64fb95d5 00000050`7c6fbfb8 00000000`ffffffff 00000050`7c6fb7e0 : nt!NtCreateFile+0x79
ffffcb82`9621f9b0 00007ffc`9be50bd4 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x25
00000050`7c6fd598 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffc`9be50bd4


SYMBOL_NAME: exfat!FppDeleteFcb+44

MODULE_NAME: exfat

IMAGE_NAME: exfat.SYS

[albinoni]

Got another blue screen crash when I did a FFS compare, same bugcheck code. windbg shows the call stack is almost identical except for these two lines
FLTMGR!FltIsCallbackDataDirty+0x4bb
FLTMGR!FltRequestFileInfoOnCreateCompletion+0x503
above is latest, the earlier one was
FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x15b
FLTMGR!FltpCreate+0x323

I actually have google drive monitoring this folder as well, for the purpose of sharing it - and I discovered the tmp.driveupload folder is from google. I could reformat the samsung drive as NTFS and take away the google drive monitoring but for now I'm gonna leave it and see if I get more crashes.

[albinoni]

Still getting crashes. It seems that the Intel CPU problems can affect non gaming PCs that aren't overclocked so now I'm gonna have to wait for the Intel 0x12B microcode fix to be available for the Gigabyte MB I have and hope the shop I bought it from are willing to replace the CPU.

[xCSxXenon]

Still getting crashes. It seems that the Intel CPU problems can affect non gaming PCs that aren't overclocked so now I'm gonna have to wait for the Intel 0x12B microcode fix to be available for the Gigabyte MB I have and hope the shop I bought it from are willing to replace the CPU.

This is correct! There really is no such thing as a "gaming" CPU, it's crunching numbers no matter what the user is actually seeing. The current 'fix' is the 0x129 microcode but you are correct that 0x12B is slated to be the 'final' version. Over the last few years, these modern chips have been overclocked out-of-the-box anyway, especially the 'K' SKUs. Overclocking isn't really the problem anyhow. The current analysis by some third parties, which we've seen consistent within our shop, is a combination of two that are contributing to the issues. One is V-droop where a CPU goes from idle to turbo quickly but the voltage doesn't keep up and the second is too much voltage being sent compared to what should be or is requested.

[albinoni]

Is it possible that the 0x12C microcode update will stop my machine from crashing and the CPU doesn't actually need to be replaced and isn't actually damaged?

[xCSxXenon]

Possible, yes. Likely, no

[albinoni]

Gigabyte put out a new BIOS with the latest 0x12B microcode and I installed it but the machine crashed 3 hours later when it was doing absolutely nothing so it's going back to the shop for hopefully a brand new CPU.

[xCSxXenon]

I'm still waiting for MSI to release a BIOS with 0x12B for my PRO Z790-A MAX WIFI.
They released 0x129 within days of release, but radio silence for 0x12B. Luckily, MSI have some of the better VRM/MOSFET setups and that can help mitigate some issues. Hopefully they get you sorted out quickly.