A customer had a major client that was encountering this error message:
INFOPATH.EXE
The system detected an overrun of a stack-based buffer in this application. The overrun could potentially allow a malicious user to gain control of this application.
(Note: Not actually InfoPath. I just substituted them for the actual program because InfoPath is no longer supported, so I hope they won’t feel bad that they’re being used as the culprit here.)
The customer’s client was extremely concerned by the admittedly alarmist text.
The customer explained that this is an operating system level error that just happens to be showing up in this case with InfoPath, but in searching the device’s history, they found at least one instance of the error occurring with a different program. This message arises from any number of so-called “fast fail” conditions that an application reports to the operating system, such as an unhandled exception or an assertion failure. Even though many different failure conditions are being reported, the message to the user always describes it as a potential buffer overflow, even though that might not be the actual reason.
The customer asked if there was any official Microsoft statement that they could point their client to.
This is a common request to the engineering group. We call it “customer-ready” text: Text that can be shared directly with a customer.
So here is some customer-ready text explaining the STATUS_ status code description.
The message is used when the program self-detects that something has gone wrong. It was originally used for buffer overrun detection but is now used for general-purpose failure detection. The error message has not been updated to accommodate the expanded usage. A more accurate description would be “This program terminated itself after encountering an internal error.”
And here I thought that this was about the other not-really-overflow status code. The one where it was detected in time that the buffer was too small and only a partial result was written.
0x80000005 STATUS_BUFFER_OVERFLOW, I think?
Why do “fast fail” errors use this status code rather than having a new one established? And why does WIL use this status rather than whatever it got in the FailureInfo? (https://github.com/microsoft/wil/blob/1fae8ac13f393d727d6c3dba50b1dfe3f63e835b/include/wil/result_macros.h#L4522)
I’m guessing because it was already an error which could occur ‘anywhere’, and thus there might already be existing ‘last chance’ error-handling logic in existing applications for it which tried to save user work before aborting or w/e & they wanted to leverage that?
Sounds like a bad idea to me b/c someone might try to recover by actually expanding the stack? (not sure if that’s actually possible in Win32)
STATUS_FAIL_FAST_EXCEPTION even exists already.
Yep, 0xC0000602: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55
Is InfoPath really dead this time? I recall Microsoft killing it at least twice already (it even got a funeral at a SharePoint Conference I think) but it kept coming back.