GNOME Bugzilla – Bug 137796
BitBlt failure reports when desktop is not visible
Last modified: 2005-10-02 20:22:02 UTC
When the windows desktop is hidden either by switching users on XP or by disconnecting from a remote desktop session, the BitBlt api call fails and a Gdk warning message is printed with the win32 explanation being that the handle in invalid. As far as I can tell, the errors are harmless and the app is redrawn when the desktop becomes visible again. It would be nice to suppress these warnings if the cause is that the desktop is not visible and to not emit expose events as long as it's not. Note that the warning suppression will still be needed if expose events are also suppressed because the drawing could occur in response to an expose event that was emitted when the desktop was visible.
Yes, warnings like gdkdrawable-win32.c:1568: BitBlt failed: The handle is invalid. gdkdrawable-win32.c:1228: LineTo failed: Access is denied. are very annoying. ;-) One can't even close the console window, as it closes the app entirely.
You can minimize console windows. Or, you can redirect an application's standard output and/or standard error to a file. Then GLib warnings and error messages will go to the file and not cause a console window to open.
*** Bug 144146 has been marked as a duplicate of this bug. ***
If anyone wants to look into this, there is a WTSRegisterSessionNotification call present in NT 5.1+ (NT 5.1 is windows XP) that will set things up so a message is sent when the a session is connected or disconnected. There are also other terminal services functions that could be useful.
(This comment has nothing to do with the BitBlt issue, but I just wanted to add it somewhere...) BTW, a code example how to prevent console windows from being closed is at http://www.codeproject.com/cpp/cppforumfaq.asp#cons_appcloses . A bit of a hack, but presumably works. It looks up the HWND corresponding to the console window by setting the title temporarily to some hopefully unique string (this is the hackish part), then uses GetSystemMenu and DeleteMenu to remove the SC_CLOSE menu entry from the console window's system menu (which apparently also means that the 'X' button gets removed. On win2k and newer, there is also the GetConsoleWindow call.
This might also belong in another bug, but maybe it would be better to direct these messages somewhere else in non debug builds so the console window doesn't come up. This could default to somewhere in the application data folder (available on 98 with IE active desktop and forward) with and api to redirect it someplace else. Message above a certain priority could also be sent to the win32 event log.
> This might also belong in another bug See related discussion in bug #141102. I'm copying my comment #5 there. I think it's up to the installer of some application to, if deemed necessary, make the thing the end-user invokes be a .bat file that redirects standard output and standard error to a log file. g_log* can't know whether called from a "debug build" of an application or not.
In principle I agree it's up to the application -- and my application does this. However, applications such as gimp (at least the build I installed via an installer) and I believe X-Chat don't do this so it might be a good idea to make this easier to do or even automatic. Or is there a call to install a log handler for all messages, regardless of domain? I didn't find one, but I may have missed it. I don't know how to redirect stderr from a batch file, actually, and batch files are often not a good idea because a dos window comes up unless it's suppressed by .pif file & the icon is not set. You're right about the debug build for most people -- though we do compile gtk and all its dependencies in debug mode during development and then with debug off for release. Though, how do you deal with linking again msvctd.dll v. msvct.dll (the debugging & non-debugging versions of the C runtime dll)?
the warning messages are not vible anymore so maybe this bug should be closed ? IMHO adding even more conditionals - i.e. something like WTSRegisterSessionNotification () isn't worth the effort ... 2004-09-22 Tor Lillqvist <tml@iki.fi> * glib/gmessages.c: [Win32] Don't ever open a console window. (Which we used to do if standard output or standard error are invalid, as they are for GUI applications.) These console windows that open up unexpectedly have caused endless amounts of confusion among end-users. (#141102, #151175)
I think it is important that GTK+/GDK never report warning or critical messages for conditions that aren't programmer bugs. Because application programmers need to be of the mindset that "every warning or critical message is a serious bug that must be fixed". Sloppy programs that assume that GTK+ was compiled with --enable-debug=[miniumum/yes] and pass NULLs into random GTK+ functions should be strongly discouraged.
So what should GDK/Win32 do then if it encounter errors caused by something being (perhaps temporarily) broken in the system, a lack of some resource, or whatever? Just be silent and assume that the user will notice if the application starts looking or behaving all strange amd terminate the application? Hmm, I guess I should check how the X11 backend handles X11 errors...
Well, this one sounds like it's entirely harmless, so it shouldn't be a warning. In general: - Application bugs: GTK+ should be noisy for the programmer, but perhaps tolerant on a deployed system. - Installation bugs: GTK+ should be noisy, so that the user gets back to the person who gaves them the installer and makes that person fix the issue. - Resource errors: There is nothing to "fix" here, so GTK+ probably should just limp along, misdraw, whatever. Certainly treating this the same as a programmer error is wrong, what's the point of printing messages to the console that noone will likely ever see. If anything the appropriate behavior would be to pop up a dialog telling the user that resources are exhausted and giving them the option to continue or terminate the program. The question is always "who could do something about the issue".
I see your point. Would it be best then to have the _gdk_win32_api_failed() and _gdk_win32_gdi_failed() functions normally be silent. Only if explicitly asked for (by setting some environment variable), should they call g_warning()? Then end-users could be instructed to turn on those messages to help debug some consistent problems they encounter.
what sort of things typically trigger failures of the win32 API / GDI? (X errors are virtually always programmer errors, and the X backend leaves them fatal rather than trying to recover)
Well, a remote desktop reconnection causing intermittent troubles like in this bug (or bug #111693, but there it causes an assert...) is typical, I guess. I don't really remember seeing warning messages from GDK/Win32 any often myself.
Normally GDI errors indicate programmer errors so they should be warnings, at least during development. It would be good here to only suppress the warning when the desktop wasn't displayed, but to emit them when it is displayed.
Fixed in gtk-2-8 and HEAD: 2005-10-01 Tor Lillqvist <tml@novell.com> * gdk/win32/gdkdrawable-win32.c (blit_from_pixmap): In case BitBlt() fails with ERROR_INVALID_HANDLE, the most probable cause is that the the desktop isn't visible because the session has been switched, the screen is locked, or a terminal server session disconnected, so no error message necessary. (#137796) It is of course remotely possible that BitBlt() failing with ERROR_INVALID_HANDLE might also be caused by some other problem. We could strive for perfection and track whether the desktop is visible by using WTSRegisterSessionNotification() and handling WM_WTSESSION_CHANGE. I think that's overdoing it just for this issue, though. If we would track desktop visibility, we should then avoid even trying to update the display at all while the desktop isn't visible.
*** Bug 109536 has been marked as a duplicate of this bug. ***