Blue Screen of Death: BsOD Win11 23H2 Arduino IDE v 2.3.4

kurtasel · January 10, 2025, 4:07am

Downloaded Arduino IDE v 2.3.4 last January 8, 2025 I experienced multiple BSoDs.
I cannot reliably reproduce the BSoD, however BSoD occures with the use of Arduino IDE.

Note: My laptop is a Thinkpad L15 (Gen1) running Windows 11 23H2 OS Build 22631.4602 AMD Ryzen 5 PRO 4650U with Radeon Graphics 2.10 GHz 48Gb RAM which has integrated Wifi and Bluetooth from Intel AX200NGW module. It seems odd that bluetooth is not detected but Wifi is present. To double check, I opened my laptop and check if the antenna is disconnected but no, it's intact and no visual evidence of disconnection.

I was programming my old (circa. 2021 bought) Arduino Nano (old bootloader) wtih CH340 UART USB chip.

ROUGH SEQUENCE OF EVENTS:

1st BSoD: after installation of ESP32 boards from the Arduino IDE Board Manager. I believe (from conjecture) that the Bluetooth drivers installed by the Arduino IDE interfered with my Laptop's bluetooth driver. Upon recovery from the BSoD, Windows 11 23H2 can no longer detect my bluetooth hardware. Usually I can turn on/off my bluetooth but I can no longer see Bluetooth options in my toolbar. Note that I still have Wifi. I also tried bluetooth troubleshooting but it says I have no bluetooth in my device. I tried verifying this with the device manager but nothing's displayed for Bluetooth including the bluetooth COM ports. I then tried to use the Arduino IDE 2.3.4 for sometime then another BSoD came along.

Note: It seems odd that bluetooth is not detected but Wifi is present. To double check, I opened my laptop and check if the antenna is disconnected but no, it's intact and no visual evidence of disconnection.

2nd BSoD: After the first BSoD, I tried again to program my Arduino Nano. However more tinkering lead me to another BSoD. After recovering from this BSOD, the Bluetooth device was detected. With this I strongly believe a driver issue. I then updated my drivers via windows update and Lenovo System Update. My bios was updated and the next restart seemingly 'recovered' my missing bluetooth device.

3rd BSoD: Thinking I shook off the problem with the newly installed bios drivers, I also uninstalled the ESP32, SAM boards from the board manager and only left the AVR boards just in case. However, another BSOD took place and then upon restart my bluetooth again is gone.

4th BSoD / can't login: after 2 restart I can no longer normally enter windows 11. It keeps displaying the BSoD and I have to boot to a previous restore point.

tried using WinDbg (Windows Debugger) to analyze the dump file from the BSoD:
It's "BAD_SYSTEM_CONFIG_INFO (74)"

I AM NOT AN EXPERT HERE. I NEED HELP ANALYZING THIS REGISTRY PROBLEM. I Believe it's a registry problem so please check it out Below is from the WinDbg analysis of the BSoD dump file


******************************************************************************

BAD_SYSTEM_CONFIG_INFO (74)
Can indicate that the SYSTEM hive loaded by the osloader/NTLDR
was corrupt.  This is unlikely, since the osloader will check
a hive to make sure it isn't corrupt after loading it.
It can also indicate that some critical registry keys and values
are not present.  (i.e. somebody used regedt32 to delete something
that they shouldn't have)  Booting from LastKnownGood may fix
the problem, but if someone is persistent enough in mucking with
the registry they will need to reinstall or use the Emergency
Repair Disk.
Arguments:
Arg1: 0000000000000002, (reserved)
Arg2: ffffc98d5f453a00, (reserved)
Arg3: 0000000000000002, (reserved)
Arg4: ffffffffc000014c, usually the NT status code.

Debugging Details:
------------------


KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.mSec
    Value: 2828

    Key  : Analysis.Elapsed.mSec
    Value: 8626

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

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

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

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

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

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

    Key  : Analysis.Version.DbgEng
    Value: 10.0.27704.1001

    Key  : Analysis.Version.Description
    Value: 10.2408.27.01 amd64fre

    Key  : Analysis.Version.Ext
    Value: 1.2408.27.1

    Key  : Bugcheck.Code.LegacyAPI
    Value: 0x74

    Key  : Bugcheck.Code.TargetModel
    Value: 0x74

    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: 0x74_2_c000014c_nt!CmpLoadHiveThread

    Key  : Failure.Hash
    Value: {635f2983-bece-5263-565c-834f3be7c2f2}

    Key  : Hypervisor.Enlightenments.ValueHex
    Value: 1497cf94

    Key  : Hypervisor.Flags.AnyHypervisorPresent
    Value: 1

    Key  : Hypervisor.Flags.ApicEnlightened
    Value: 1

    Key  : Hypervisor.Flags.ApicVirtualizationAvailable
    Value: 0

    Key  : Hypervisor.Flags.AsyncMemoryHint
    Value: 0

    Key  : Hypervisor.Flags.CoreSchedulerRequested
    Value: 0

    Key  : Hypervisor.Flags.CpuManager
    Value: 1

    Key  : Hypervisor.Flags.DeprecateAutoEoi
    Value: 0

    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: 4853999

    Key  : Hypervisor.Flags.ValueHex
    Value: 4a10ef

    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:  74

BUGCHECK_P1: 2

BUGCHECK_P2: ffffc98d5f453a00

BUGCHECK_P3: 2

BUGCHECK_P4: ffffffffc000014c

FILE_IN_CAB:  010825-12062-01.dmp

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


DUMP_FILE_ATTRIBUTES: 0x1808
  Kernel Generated Triage Dump

FAULTING_THREAD:  ffffcc08ee9ba080

ERROR_CODE: (NTSTATUS) 0xc000014c - {The Registry Is Corrupt}  The structure of one of the files that contains Registry data is corrupt, or the image of the file in memory is corrupt, or the file could not be recovered because the alternate copy or log was absent or corrupt.

CUSTOMER_CRASH_COUNT:  1

PROCESS_NAME:  Registry

STACK_TEXT:  
ffffc98d`5f453908 fffff800`73112ae1     : 00000000`00000074 00000000`00000002 ffffc98d`5f453a00 00000000`00000002 : nt!KeBugCheckEx
ffffc98d`5f453910 fffff800`72b4d247     : ffffcc08`ee9ba080 ffffcc08`ee9ba080 fffff800`7301e650 00000000`00000002 : nt!CmpLoadHiveThread+0xf4491
ffffc98d`5f453bf0 fffff800`72c1a084     : ffffb581`29157180 ffffcc08`ee9ba080 fffff800`72b4d1f0 00000000`00000246 : nt!PspSystemThreadStartup+0x57
ffffc98d`5f453c40 00000000`00000000     : ffffc98d`5f454000 ffffc98d`5f44e000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x34


SYMBOL_NAME:  nt!CmpLoadHiveThread+f4491

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

IMAGE_VERSION:  10.0.22621.4601

STACK_COMMAND:  .process /r /p 0xffffcc08e91e4040; .thread 0xffffcc08ee9ba080 ; kb

BUCKET_ID_FUNC_OFFSET:  f4491

FAILURE_BUCKET_ID:  0x74_2_c000014c_nt!CmpLoadHiveThread

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {635f2983-bece-5263-565c-834f3be7c2f2}

Followup:     MachineOwner
---------

For Now, I jsut Use VSCode with Platfor.io. I want to use simple Arduino IDE just to check and uplaod codes

ptillisch · January 10, 2025, 5:15am

Hi @kurtasel.

Please do this:

Connect your cheap Nano derivative board to your computer with a USB cable.
Open the Windows Device Manager.
Select View > Devices by type from the Device Manager menus.
Open the "View" menu.
If there is a ✓ to the left of the "Show hidden devices" menu item, click on "Show hidden devices" to disable it.
Open the "Ports (COM & LPT)" section of the Device Manager tree.
You should see a port identified as "USB-SERIAL CH340 (COMn)" under the "Ports (COM & LPT)" section (where "COMn" is some serial port e.g., COM4). Double click on that item.
The "USB-SERIAL CH340 (COMn) Properties" dialog will open.
Select the "Drivers" tab of the "USB-SERIAL CH340 (COMn) Properties" dialog.

Now please reply here on the forum thread to tell us the version number you saw after "Driver Version" field in that "USB-SERIAL CH340 (COMn) Properties" dialog.

Arduino IDE doesn't install any Bluetooth drivers.

mdurfee · February 13, 2025, 9:21pm

One of my students is having the same problem. Driver version is 3.9.2024.9 I had them update the driver.

mdurfee · February 13, 2025, 9:23pm

I actually have had several students experience BSOD randomly this semester while use the IDE. It wasn't happening before this semester.

kurtasel · February 13, 2025, 11:22pm

Has the BSoD returned after updating the drivers?

also have you tried using old Arduino v1.8? Perhaps it’s a more stable version.

mdurfee · February 28, 2025, 8:40pm

Several students have indicated that the BSOD problem decreased, but did not dissappear.

kurtasel · March 7, 2025, 11:35pm

Not a good sign. Probably be swtiching to v1.8. Also, CP2102 drivers for the Arduino baords, do they also have issues?

mdurfee · March 8, 2025, 12:11am

Thank you for the advice. We will switch to the earlier version.

I can't say about the other driver. We only use the CH340 driver.

ptillisch · April 4, 2025, 5:20am

Hello again @kurtasel and @mdurfee. A potential fix has been made in the serial-monitor helper tool that provides communication between the Arduino IDE 2.x Serial Monitor tool and the serial port of the Arduino board:

github.com/bugst/go-serial

Hack to workaround misbehaving CH340 drivers on Windows

master ← cmaglie:CH340_hack

opened 01:37PM - 17 Mar 25 UTC

cmaglie

+47 -22

It seems that the CH340 driver does not correctly support the `SetCommTimeouts` …system call. In particular calling `SetCommTimeouts` with the following settings ``` Windows.CommTimeouts{ ReadIntervalTimeout: 0xFFFFFFFF, ReadTotalTimeoutMultiplier: 0xFFFFFFFF, ReadTotalTimeoutConstant: 0xFFFFFFFE, } ``` should set timeout to infinity and block the `Read` call until at least one byte is received. In reality, the CH340 behaves like there is no timeout, returning the available data immediately (or an empty read if there is no data). This violates the [`SetCommTimeout` definition](https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setcommtimeouts), while all the other drivers [correctly honor the timeout](https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-commtimeouts#remarks). > If an application sets ReadIntervalTimeout and ReadTotalTimeoutMultiplier to MAXDWORD and sets ReadTotalTimeoutConstant to a value greater than zero and less than MAXDWORD, one of the following occurs when the [ReadFile](https://learn.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-readfile) function is called: > > * If there are any bytes in the input buffer, [ReadFile](https://learn.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-readfile) returns immediately with the bytes in the buffer. > * If there are no bytes in the input buffer, [ReadFile](https://learn.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-readfile) waits until a byte arrives and then returns immediately. > * If no bytes arrive within the time specified by ReadTotalTimeoutConstant, [ReadFile](https://learn.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-readfile) times out. Notably, the wrong behavior is present only with the "block until the first byte is received" timeout mode. Using the "block until the buffer is full" timeout mode ``` Windows.CommTimeouts{ ReadIntervalTimeout: 0, ReadTotalTimeoutMultiplier: 0, ReadTotalTimeoutConstant: 0, } ``` works as expected and the `Read` call lasts until the buffer given to the `Read` call is filled. BTW this kind of timeout is not useful for us because it will force us to do an inefficient read of one byte at a time if the amount of data received is not known in advance. Another interesting discovery is that after setting a finite timeout (like for example 10 seconds): ``` Windows.CommTimeouts{ ReadIntervalTimeout: 0xFFFFFFFF, ReadTotalTimeoutMultiplier: 0xFFFFFFFF, ReadTotalTimeoutConstant: 10000, } ``` the CH340 behaves correctly and waits 10 seconds for the first byte to come in. This made me think that maybe it's the highest value `0xFFFFFFFE` that is not correctly interpreted by the driver, so I started searching the maximum-working-value, and after bisecting for a bit, I've found the "magic" number that finally makes the driver behave again: `0x7FFFFFFE`. This makes me think that the bug in the driver is due to a signed-vs-unsigned comparison. In any case, reducing the "infinity" value from `0xFFFFFFFE` to `0x7FFFFFFE` does solve the problem, and it keeps the library compatible with the other serial converters. Actually, it does halve the "infinity" timeout from circa 50 days (FFFFFFFE milliseconds) to 25 days (7FFFFFFE milliseconds), BTW I've added another patch that will transparently repeat the `Read` if this very long timeout should ever happen.

Arduino IDE 2.x automatically updates the serial-monitor when a new version is available, so the version with the fix (0.15.0) should already be installed on your computer and in use by Arduino IDE 2.x.

I already verified that the change another problem that affected boards with the CH340 chip (arduino/arduino-create-agent#1000). However, I was never able to reproduce the problem reported here, so I am not able to check whether it is fixed or not.

Please check to see if the problem occurs when using the latest driver version and then add a reply here on the forum topic to let me know what you found.

I'll provide instructions you can follow to do that:

Connect the Arduino board to your computer with a USB cable.
Open the Windows Device Manager.
Select View > Devices by type from the Device Manager menus.
Open the "View" menu.
If there is a ✓ to the left of the "Show hidden devices" menu item, click on "Show hidden devices" to disable it.
Open the "Ports (COM & LPT)" section of the Device Manager tree.
You should see a port identified as "USB-SERIAL CH340 (COMn)" under the "Ports (COM & LPT)" section (where "COMn" is some serial port e.g., COM4). Double click on that item.
The "USB-SERIAL CH340 (COMn) Properties" dialog will open.
Select the "Driver" tab of the "USB-SERIAL CH340 (COMn) Properties" dialog.
Click the "Update driver" button.
An "Update Drivers Device - USB-SERIAL CH340 (COMn)" dialog will open.
Click on "Search automatically for drivers" in the "Update Drivers Device - USB-SERIAL CH340 (COMn)" dialog.
You should now see the driver installation wizard update the driver. Wait for the update to finish, as indicated by the message "Windows has successfully updated your drivers" in the dialog.
Click the "Close" button in the "USB-SERIAL CH340 (COMn) Properties" dialog.
Close Windows Device Manager.
Save any unsaved work that might be present in your open applications to ensure you won't lose anything if a BSoD does occur.
Start Arduino IDE 2.x.

Upload the "hello" test sketch to the board:

void setup() {
  Serial.begin(9600);
}
void loop() {
  Serial.println("hello");
  delay(5);
}

Open Serial Monitor.

Hopefully this time a BSoD will not occur.

Topic		Replies	Views
IDE cause BSOD in Windows 11 IDE 2.x	13	761	April 4, 2025
Bluescreen of death while using IDE: "Stop code: DRIVER_IRQL_NOT_LESS_OR_EQUAL" IDE 2.x	4	92	April 4, 2025
IDE crashes my computer IDE 2.x	32	490	April 5, 2025
Sudden Issue: BSODs on 4 Different Laptops Using Arduino Mega (CH341) in Classroom Today (First Time in 3 Months) General Discussion	14	723	April 4, 2025
Windows 10: bluescreen on excessive Serial.prints IDE 2.x	21	908	April 4, 2025

Blue Screen of Death: BsOD Win11 23H2 Arduino IDE v 2.3.4

Related topics