2
votes

Does anyone know how MessageBox(...) could fail silently?

MessageBox(g_hMainhWnd, buffer, "Oops!", MB_OK | MB_ICONERROR);

ShellExecute(0, "open", "http://intranet/crash_handler.php", NULL, "", SW_SHOWNORMAL);

For a little context, this code is called inside our own exception handler, which was registered with SetUnhandledExceptionFilter()

Most of the time, I see the message box, and then it launches a web browser.

However, I have an exe, which as far as I'm aware uses this exact code, and it successfully launches the web browser, but I do not see the message box first.

Thanks

Tim


Cracked it. I tried deliberately passing in a garbage HWND and the message box didn't appear.

Thanks Brian!

2
When it does fail, what does actually happen? Does the process terminate? Does MessageBox return 0? Do you cann GetLastError() to determine the cause?John Dibling
Unfortunately I no longer have access to the code which built the exe, so I can't trace that exactly. Thanks for the suggestions though.Tim Gradwell

2 Answers

5
votes

Just an idea but maybe g_hMainhWnd is invalid? See if it works when you put NULL for the first parameter.

I would suggest to call GetLastError after the call and write the output to a file. That way you can see what Windows thinks the error is. The MSDN MessageBox documentation mentions that it sets GetLastError for this API and if it fails it returns zero.

0
votes

This is a common problem in Windows Mobile whenever an error triggers a shutdown (which I'm assuming is what's happening in your case, given the URL you're going to). Even when you catch the unhandled exception, you can execute a bunch of statements reliably before the application then closes, but MessageBoxes may or may not be displayed. They're almost always displayed when running the app in debug through Visual Studio, but they almost never appear when the app is run as a compiled EXE.

Weirdly, if you call MessageBox twice in this situation, the second call usually shows a box (even in the EXE).

I don't know if the same problem exists with regular Windows, but it sounds like you're describing the exact same situation. Complete guess here, but it's possible that the Windows OS is aware that the application requesting the message box is in its death throes, and sensibly ignores the request (in the olden days, dying apps often used to throw up a barrage of "help me, I'm dying" message boxes).