About once a week a i get a bug check code 139 error reboot on my Windows 11 PC running the latest version of Glasswire. The WinDbg analysis gives the follow cause:
ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.
Hello, I think it could be the non-legacy GlassWire driver. Indeed the common causes of that error are mostly related to drivers Bug Check 0x139 KERNEL_SECURITY_CHECK_FAILURE - Windows drivers | Microsoft Learn Moreover another user had the same issue some months ago KERNEL SECURITY CHECK FAILURE 0x139 That user was using 32-bit GlassWire as the post is dated back to March but I guess that since your OS is 64-bit you were using 64-bit GlassWire before reverting to a older version. If this is the case the same error can occur both on 64-bit GlassWire than on 32-bit GlassWire. Maybe both versions use the same non-legacy driver, I would not know.
The “Use Legacy Driver” installation option has been removed in 64-bit GlassWire and some other users had to revert to 32-bit version to use Legacy driver because they had different issues so I wonder why 64-bit GlassWire was released as official version and not as beta version.
I’m not a technician but it’s better to use the standard driver, when possible. Sometimes it is necessary to revert to the legacy driver to fix issues. For example me and other users had some issues with Adguard for Windows which randomly caused some BSOD’s.The developers suggested to disable Adguard for Windows WFP (Windows Filtering Platform) driver (adgnetworkwfpdrv.sys) to use the TDI (Transport Driver Interface) Legacy driver (adgnetworktdidrv.sys), older but more stable.
In general:
Standard Drivers
Active Support: Updated regularly for new software, games, and operating system kernels.
Performance: Optimized for maximum speed and efficiency on modern systems.
Target Hardware: Current-generation and recent previous-generation devices still supported by the manufacturer.
Legacy Drivers
Maintenance Mode: Receives critical security or system-breaking bug fixes only.
Feature Freeze: Does not include enhancements, speed optimizations, or support for new software/games.
Target Hardware: Older or obsolete hardware that has reached end-of-life status from the active development branch.
Was this problem solved? I get random reboots also for the last 4 months. The event viewer for me points to Intel Killer suite. There are numerous posts recommending to delete them but where does the Nic connectivity come from? I got crucified on other sites for not doing clean installs and for digging deeper. The win databse, Intel, NTFS ssd system show up as the problem. They are not. I have no hardware issues. I have to run sfc /scannow weekly. DISM doesnt seem to make the necessary repair either.
I started to get issue approx 3 months ago, using 32 bit driver. Took some time to get to bottom of where issue was coming from (had done the usual windows, driver updates first, windows install repair ). Once had done the bug dump file analysis I found switching to the legacy driver solved problem then with latest update got the 64 bit version which no longer includes legacy driver and reboots are happening again, just less often. Am running 3.9.1102
Hello, if you were using a 64-bit OS then the GlassWire standard driver was 64-bit too because as far as I know 32-bit drivers can’t run on a 64-bit OS so I think that both 32-bit GlassWire than 64-bit GlassWire are using the same 64-bit standard driver which could be the reason of the issue. I could be wrong, though, because as I wrote above I’m not a technician or a programmer.
What changes between 32-bit GlassWire and 64-bit GlassWire is the architecture of the software because, in general:
The main difference between 32-bit and 64-bit software is how much computer memory (RAM) each program can use at one time. 32-bit software is limited to using 4 GB of RAM per process, while 64-bit software can access vastly larger amounts of memory, making 64-bit the modern standard for speed and performance.
Memory Limits
32-bit software: Can only see and use up to 4 gigabytes (GB) of RAM total. If a large game or editing tool needs more, the program can slow down or crash.
64-bit software: Can use terabytes or exabytes of RAM. It handles heavy data load without running out of room.
Speed and Performance
32-bit software: Uses smaller data chunks and fewer processor registers (storage slots inside the CPU).
64-bit software: Processes larger chunks of data at once and utilizes extra CPU registers, making heavy tasks like video rendering, scientific computing, and gaming run faster.
Compatibility
32-bit software: Can run on older 32-bit systems and most 64-bit operating systems via a compatibility layer. However, it cannot use modern 64-bit hardware features.
64-bit software: Requires a 64-bit operating system and a 64-bit processor to run. It will not work at all on older 32-bit computers.
I found this thread in the search for the event viewer line item. I am a licensed Glasswire seat although it hasnt been running for 4 months since the reboot loops. I was Sherlocking the system an app at a time. My machine is an MSI Titan-18-hx-a14vig-088US K2402N0029562. Still the largest laptop one can buy. I run Blender, Unity, Freecad, Kicad, Orca and Prusa so I beat this machine up to its limits. That being said when the reboots started that happen what ever app I was in I would blame or that was the current focus. Well it happened in all those apps and what I found was the threads for those app all had the crashes/reboot loops. All applications are in 4 places, storage, cpu, gpu or ram. If all the apps were crashing from storage the machine would be toast all over the place. It looks like this if one wants to succumb to the mystery. In my computer decades it all points to page faults which a 64 machine trying to babysit a 32 bit app/driver would expose this. Hence the dump below. Now its not fair to have company A solve company B’s software problem which is where the support industry is because of things WE dont like or need in our systems. But the 30k foot is necessary to look at regardless of whats under our feet/hood.
Bleeping computer has stated they dont want to support me until I do a clean install. Thats like razing and rebuilding the house because a drain is clogged. SFC and DSIM cant fix whats wrong either. There is something that MS isnt performing correctly or deeply. Somebody is going to find the permanent fix somewhere. I hope this insight helps anybody who gets here.
Bugcheck analysis
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000300000000, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff804a4fe590e, address which referenced memory
Glasswire would be king of the planet if they found the solution. The everyday app devs dont deal with mem leaks. They just write apps and set them loose. Glasswire on the other hand has to be more concerned with system fits.
Let me add this bullet to the campfire. After 4 months of the BleepingComputer processes my machine worked fine for a week. Then the reboots started. Now they are like clock work on Wednesday or Saturday. Anybody wanna take a guess of that schedule? MS updates. I live with it for now but my curiosity still wants a fix. So I show up in these app threads.