What is the history of the ERROR_ARENA_TRASHED error code?(devblogs.microsoft.com)
devblogs.microsoft.com
What is the history of the ERROR_ARENA_TRASHED error code?
https://devblogs.microsoft.com/oldnewthing/20260519-00/?p=112339
17 comments
Oh this is great to know! I actually used this before when writing an arena allocator, since it seemed to be relevant and was already built into a system that was relying on WIN32 and HRESULT errors to begin with. I always had fun trying to find existing error codes among Windows' header files to use for other things.
I wonder if performing a system scan or file check has ever actually fixed any errors. Rebooting on the other hand, fixes basically any transient problem I encounter, even on non-Windows machines (a friend who has a Mac doesn't always believe me when I tell them to reboot to fix random unusual slowness/hangs, but they have only 8GB of memory and it has always worked so far!)
I will say though, non-Windows machines rarely need a reboot while Windows often should practically be rebooted daily.
I will say though, non-Windows machines rarely need a reboot while Windows often should practically be rebooted daily.
Since nearly every consumer machine uses non-ECC RAM it's probably best to just do a full shutdown at night and boot up the next day.
It reminds me of "bitsquatting" where you can get a lot of hits for domains 1 bit off really popular domains (separate from likely typos).
It reminds me of "bitsquatting" where you can get a lot of hits for domains 1 bit off really popular domains (separate from likely typos).
I doubt random bitflips are the source of most NT invariant violations. A reboot does fix them all the same though.
Bitflips are surprisingly more common than you think but rare enough to not be a concern.
If you have ECC memory, you can actually monitor this.
I've typically seen ~a dozen bitflips per year per machine when I looked at this on servers, except for the cases of a faulty RAM module.
I am more worried about SSD corruption than RAM bitflips from data I've seen on my systems.
I've typically seen ~a dozen bitflips per year per machine when I looked at this on servers, except for the cases of a faulty RAM module.
I am more worried about SSD corruption than RAM bitflips from data I've seen on my systems.
In practice I've had system file checks find and repair errors on multiple different machines. These setups aren't using ECC RAM or RAIDed storage, though.
My Windows machine goes weeks between reboots which are 95% of the time due to software updates, occasionally I restart just Explorer itself which can glitch out.
I think it’s largely a factor of what additional drivers, services and security software are installed.
My laptop (very deliberately) only has the integrated Intel GPU, uses vanilla Windows Defender and I avoid installing any additional stuff, e.g, stick to just Dell’s Command | Update as opposed to having any of their other completely unnecessary software installed, also always avoid their SupportAssist.
I also have Windows 11 widgets turned off and have set the registry key which stops web results appearing in the start menu search which changes it to work really well as opposed to constant source of frustration. (Similarly, I found on iOS turning off Safari results from global search also a huge quality of life improvement.)
I think it’s largely a factor of what additional drivers, services and security software are installed.
My laptop (very deliberately) only has the integrated Intel GPU, uses vanilla Windows Defender and I avoid installing any additional stuff, e.g, stick to just Dell’s Command | Update as opposed to having any of their other completely unnecessary software installed, also always avoid their SupportAssist.
I also have Windows 11 widgets turned off and have set the registry key which stops web results appearing in the start menu search which changes it to work really well as opposed to constant source of frustration. (Similarly, I found on iOS turning off Safari results from global search also a huge quality of life improvement.)
I don't ever recall seeing this error on DOS, what would cause it to manifest? Is this one of those oddballs that you'd only see if your memory was bad, but not bad enough to throw a parity error or fail to POST?
MS-DOS doesn’t have memory protection, so another option is that the running program[1] or something like a TSR or driver could have corrupted the headers.
[1] I guess in a modern system a process can still trash its own malloc, but not the kernel’s page allocation data.
[1] I guess in a modern system a process can still trash its own malloc, but not the kernel’s page allocation data.
Oh sure, and that happened a lot, but you'd usually see a gp fault before you would anything obscure...
You wouldn’t be getting a protection fault when protection isn’t enabled.
I should also note this error is the return code for MS-DOS’s memory management functions (such as int 21h ax 48h / 49h), vaguely similar to malloc() returning NULL. It’s not a fatal error, so how it’s handled depends on the programme. It could bail out, perhaps with a more general “out of memory” error, or try and carry on, or perhaps just start overwriting parts of the interrupt vector table as that’s where segment 0007h would start at…
(Though in the latter case on DOS just blindly assuming a memory allocation worked would be rather unwise so you’d hope just about everything checks the carry flag first).
I should also note this error is the return code for MS-DOS’s memory management functions (such as int 21h ax 48h / 49h), vaguely similar to malloc() returning NULL. It’s not a fatal error, so how it’s handled depends on the programme. It could bail out, perhaps with a more general “out of memory” error, or try and carry on, or perhaps just start overwriting parts of the interrupt vector table as that’s where segment 0007h would start at…
(Though in the latter case on DOS just blindly assuming a memory allocation worked would be rather unwise so you’d hope just about everything checks the carry flag first).