- In UserpCaptureStringParameters(), always capture the parameter
strings with a terminating NULL. Also, no need to convert them to
ANSI if they are used with a STATUS_SERVICE_NOTIFICATION message.
- Determine within UserpFormatMessages() the message box flags to be
used, either from the message parameters (if STATUS_SERVICE_NOTIFICATION)
or from the proposed response options and message status severity.
These flags are then used by both UserpShowInformationBalloon()/UserpShellHardError()
and by UserpMessageBox().
- Improve Message validation (especially for STATUS_SERVICE_NOTIFICATION).
- Try to display the hard error status number if it's an unknown one.
- Make UserpFormatMessages() always succeed by falling back on
static string buffers if allocating large string buffers fail due to
lack of memory. Then the hard error popups will have truncated
strings, but at least something will be displayed instead of nothing,
thus alerting the user that something went wrong anyway.
- Simplify a bit the code by moving the NtOpenProcess(),
UserpCaptureStringParameters() and UserpFreeStringParameters() calls
inside UserpFormatMessages(). This also allows simplifying its
prototype.
- Cache localized hard error message components: the status severity,
the system process name and the unhandled exception debug strings.
- Try not to fail too much. In particular, don't fail if a string could
not be correctly captured in UserpCaptureStringParameters() (we then
use a default empty string). The next aim is to make UserpFormatMessages()
not failing at all.
- Use RtlStringCbPrintf(Ex)W where possible so that one can use counted
(and not NULL-terminated) UNICODE_STRINGs where possible. This allows
using counted resource strings without having to allocate memory.
- If available, prepend the window title of the application that
triggered the hard error to the hard error message box caption.
In particular do not always fail as soon as there is an error, because they may be the sign of an OS problem and this is precisely in this case that we want to display a hard-error.
- Use hard-error captions depending on the status code severity.
- Improve handling of the STATUS_UNHANDLED_EXCEPTION error. Start
implementing the display of the dialog button descriptions ("OK" to
terminate the application; "Cancel" to debug the application).
- Add support for the "ErrorMode" and "ShellErrorMode" registry values
under HKLM\System\CurrentControlSet\Control\Windows.
- Use MessageBoxTimeoutW() in UserpMessageBox() to support different
message box timeouts.
- Log hard errors into the System event log.
SendNotifyMessageW: It doesn't support messages with pointers so there is no need to call MsgiUMToKMMessage
SendMessageTimeoutW, SendMessageTimeoutA: These two do support marshaling pointers so they need to use MsgiUMToKMMessage.
This is actually a bug that happens only in the rare case where we send a WM_COPYDATA with a timeout.
We applied this patch also last second in 0.4.7rls, now in master.
IntTrackPopupMenuEx() caused the BSOD when called while window is in the process of being destroyed.
