Thoughts from the EPS Windows Server Performance Team
Useful Microsoft Blogs
Hi all, Paras here..
Starting with Windows Vista, the operating system has implemented a feature where an application that is seen as being unresponsive will ‘ghost’ the window to let you know something is wrong. Once the application recovers, the application regains focus and functionality and continues on.
The operating system marks the application as Not Responding if it is no longer replying to windows messages. Generally, window messages should be handled in a separate thread so the app does not appear to freeze while processing. The grey screen is a design change added to Vista and higher operating systems wherein the top-level windows that are owned by the program are supposed to be replaced by a ghost window until the program resumes. If the top level UI thread has not processed messages for more than 5 seconds then the OS will mark the app as “Not Responding”. In this case, the system hides the window and replaces it with a ghost window. This is called Window Ghosting When the program resumes, the ghost windows are replaced by the program windows.
Here is an example of what this behavior looks like:
While this behavior has a perfect logical explanation it may be annoying to many. Especially if they have recently migrated from XP/2003 to a Vista/Win 7/2008/2008 R2, many users may get confused with the sudden change in behavior. Though even earlier the application would simply sit idle and not respond to your requests but would not say “Not Responding”. However now the application title bar shows as “Not Responding” and then covers itself with a grey screen which may prompt the user to kill the application from the Task Manager.
So, if for instance you have a program that commonly encounters this behavior, you can disable it in your application by calling the DisablePRocessWindowsGhosting function. However, if you are not a developer and can’t change the program’s code, this of course won’t work for you.
But this does not mean that we will have to live with the behavior if you don’t want to. The Application Compatibility Toolkit can come to rescue here. ACT includes a compatibility fix called NoGhost that does just that.
Here is how you can use the Application Compatibility Toolkit to create and install a custom Application Compatibility database to disable the Ghost Window feature for your program.
To download the Application Compatibility Toolkit, visit the following Microsoft Web site:
To create a custom Application Compatibility database:
1. Install and run the Compatibility Administrator Tool.
2. Right-click Custom Database, and then click New.
3. Right-click the new database, and then click Rename.
4. Type noghost as the name of the database. (You can name this whatever you want.)
5. Right-click New Database, click Create New, and then click Application Fix. Type the name of the program to be fixed.
6. Type the name of the program manufacturer.
7. Locate and then select the appropriate program (.exe) file.
8. Click Next.
9. In the Compatibility Modes window, click None, and then click Next.
10. In the Compatibility Fixes list, click NoGhost.
11. Click either Test Run or Finish. Clicking Test Run starts the program with the application compatibility setting. Clicking Finish adds the compatibility fix to your database.
12. On the File menu, click Save to save the database. Or, copy the database to the C:\Windows\AppPatch folder.
13. Right-click the database, and then click Install. Or, run the sdbinst c:\windows\apppatch\noghost.sdb -q command to install the database.
After this, the ghosting of the window in question should be a thing of the past.
Till next time…
I think I'd like the opposite feature. There are times when an application as stopped responding to input, but Windows isn't ghosting the app. So the message pump must be responding, but all the new calls are getting blocked/dropped by something. So I would like it if I had a way to force ghosting so I could get a crash dump and report the problem to Microsoft.
good to know from the developer's point of view, might be handy when creating application for new OS's.
Yeah, you have not provided a convincing motivation for applying this shim: with the shim applied, users will be unable to move or minimize the app's windows when they're not responding; how exactly is that useful?