Why are Window Captions Black and Buttons frameless sometimes during debugging - c++

When debugging my Win32 Applications windows and dialogs sometimes (rarely) do not appear in the chosen Windows scheme, but rather reduced or broken:
The Window captions are all black (instead of blue or silver) and without any shadow. The Buttons doe not have any Button shape ("Abbrechen" in the screen shot). The black bar at the lower half is a windows progress bar. It doesn't show any progress when this happens.
The screen shot (details in the center greyed out) was taken from a 64-Bit application debugged under Visual Studio 2010 on XP SP3 x64 and a 10 GB machine. The was plenty of RAM (some GB) spare.
Does anyone have a clue for the reason? I never do non-client area drawing or something.
EDIT: The symptom only occurs when the Visual Studio Debugger has been attached to the program. But even when the application has been detached from the debugger the problem remains. It does not occur when starting the program without debugging.

There are at least two possibilities.
You use some other "theme engine" than the XP native, for example Clearlooks, etc. These engines may not always comply with all thing debuggers want, they may leave their message pump unpumped on some implicitly assumed (in debugger) point, and then the drawing just stalls. Same thing often happens when using some virtual desktop manager on windows, windows window manager is simply too hardwired..
Even 32bit programs in 32bit windows may run out of handles, this often results in windows starting being rendered with "Fixedsys" font. Your application shows symptoms only for Theme handled portions, which kind of indicates the possibility nr.1 again.
Try inspecting relevant windows with WinSpy and Process Explorer, unreasonable amounts of allocated resources may hint on what kind starvation is going on.

Have you installed SP1 for Visual Studio 2010? I haven't had this problem yet, but know that SP1 fixed a lot of problems with VS2010.
The other thing I do know is that WinXP x64 (which is still sp2 and not 3 btw) doesn't always play nice. It's not as well supported as the x86 version. Win Vista and 7 x64 allows for much smoother operation. (I have had some bad experiences with XP x64 myself)

We encounter this kind of trouble. In fact it was due to our antivurus (not sure but I think it was McAfee Viruscan at the moment).

I read about such symptoms (a while ago) so i googled it again and found the forum.
There seems to be an issue with some NVIDIA-drivers on WinXP-64. Also some people could get rid of the problem by reducing hardware-accelaration.
You might read the following forum (5 pages) yourself and decide if it applies to your situation.
http://forums.nvidia.com/index.php?showtopic=67608

To enforce visual styles in your application make sure to call it before you run your window, like this:
static void Main()
{
Application.EnableVisualStyles();
Application.Run(new Form1());
}
I've had the same problem happened before, particularly when using 3rd party components that use their own styling methods like Infragistics or ComponentOne

Related

What is the effectiveness of using the compatibility feature for older operating systems in Windows XP, Vista, 7 and 8?

I've been trying to research why certain compatibility features differ based on operating system so I can program a patch. I'm using the compatibility settings in the registry for Windows 95 to run a game (that of which the game was produced on) in each system. In Windows XP, the game runs perfectly. None of the scenes lag, and the sound works just as well as the scenes. I'm unsure of how it runs in Windows Vista, but in Windows 7 & 8 the compatibility feature breaks the game. I used a VM to run XP, but that doesn't effect the game's playability; real XP users have tested it. Whenever I play the game using the Win95 setting for compatibility in 7 & 8, everything lags. The music doesn't slow down during gameplay, but the graphics do. During cutscenes, they literally break. Everything pixelates, white noise and static increases volume, and the video lags every two seconds.
I therein tested it in Ubuntu Linux via WINE, and it runs better than it does in XP. I just had to use the alsa sound driver. What changed? If so, is it programmatically fixable? I'm using an amalgamation of C++, Batch and Java.
If it is necessary, the video game is entitled "The Neverhood."
Thanks.
The compatibility feature available in the shell is just scratching the surface of the "Application Compatibility" subject in Windows.
There is a tool called "Microsoft Application Compatibility Toolkit (ACT)" (that exist since Windows XP exist I believe) that has much more to offer, so maybe that can help.
For example here are some compatibility settings for Graphics Control Issues
I currently play "The Neverhood" on Win7 x64 without any visual problem, you are right when I played on Win7 for first time (4 years ago) was a headache and a little tricky to do the correct compatibility flags for each win version but finally I wrote this reg code for Win7 and worked for me while 4 years, sure it will work for you too:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Folder\\nhc.exe"="# WIN95 256COLOR 640X480 DISABLEDWM"
Where "C:\\Folder\\nhc.exe" of course is the path to your Neverhood. (Notice the double backslashes)
that flags means: Change Display color to 256 colors, change display resolution to 640x480, disable Themes service (DWM Service).
I hope this help you.
This may not answer the question directly, but if you want to improve performance of The Neverhood, change the compatibility to run in Windows 95 - then switch all other options ON, except the bottom three. This helps to make the game as fast and smooth as possible.

Windows 8 with C++ directx9 debug output

I have a game that I need to figure out a specific issue.
When you maximize, move or resize the window the DirectX device resets. But before it resets all graphically allocated objects should be released that are not part of the managed pool.
As for this game there seems to be 30 unreleased objects when the application quits (from basic directx debug library output) which leads me to assume that when the device is reset, the same issue occurs. This causes the game to crash when you maximize, move or resize the window which is obviously not acceptable.
More research has resulted in that you can enable excessive debugging in DirectX via DirectX Control Panel, except if you have Windows 8 no such thing is available. You can install the DirectX sdk and open the DirectX Control Panel, but all the features on Direct3D tab is grayed out. This excessive debug output level would then print out the addresses of allocations that have not been released upon exit, which could give me a clue of what is actually not released during a reset device event.
The game is built in C++ using DirectX 9 libraries with Visual Studio 2010.
Ps. Windows 8 comes with DirectX SDK by default but no control panel options, you must manually install the DirectX SDK to get it.
My question is, how can I enable excessive directx debugging on my environment (Windows 8 Pro)?
Are there any way you could potentially enable excessive debugging per application in the source while its compiled with directx debug libraries, or must you use the DirectX Control Panel for that?
Cheers, Nicco.
You can enable some debugging through the registry as mentioned here
Also, I played around with the control panel and noticed it modifies the following keys on my (windows7) machine:
HKEY_CURRENT_USER\Software\Microsoft\Direct3D\ControlPanel
Checking "Use Debug Version of Direct3D9" in the control panel set the "LoadDebugRuntime" registry key to a value of 1 (otherwise it was 0).
Checking "Break On Memory Leak" set the "BreakOnMemLeak" key to 1.
Checking "Break On D3D Error" set the "BreakOnDPF" key to 1.
Note that these same keys were also duplicated at:
HKEY_CURRENT_USER\Software\Microsoft\Direct3D\
So if you don't have the control panel installed they might work there as well.

Direct3D app runs fine if Windows Explorer is running, slows down terribly otherwise

Our Direct3D9 app works perfectly if we fully start Windows, and then launch it.
However, if we tweak Windows' startup process so that Explorer is not ran, and just Windows and our application are started, our app slows down horribly. CPU consumption goes to 50%, even when idle (normally, it's near 0).
This can be fixed by starting the Task Manager, starting Explorer and restarting our app. But that's not acceptable; our app must run without Explorer.
Could this be a Direct3D thing? Our app is full screen, Windows version is XP SP3 with all latest updates, and Direct3D version is 9.0.c. If this is not Direct3D related, how could I go about debugging this?
Solved it. Went to Control Panel->UserAccounts->Change the way users log on or off and saw that "Use the Welcome screen" was checked.
Unchecking that solved it. It seems that when the Welcome screen is active, since it uses a different resolution than the desktop's, conflicts ensue. And I didn't check, but it seems that this caused hardware acceleration to be temporarily unavailable and thus software rendering was selected, killing the CPU.

openGL screensaver causes problems

I have an application written in QT4, that uses an openGL window. It has been running happily for months. Windows XP, service Pack 3,
Recently I was diddling with my screensaver, and happened to select the 3D text choice. When I previewed it, the QT4 application seg-faulted immediately. When I ran in the debugger,it is crashing in ig4dev32.dll, which is an intel graphics accelerator driver for Open GL.
When I do a similar test on a machine with an NVIDIA card, I (not surprisingly) get no problems.
I'm not really sure whether I'm asking for help, or insight, or whatever--has anybody ever seen it? Google tells me others have seen it happen in gaming applications, but I see no references to developers having it happen to them. Obviously, I can not use that screensaver, but I suspect the problem is "bigger" than that. Ideas?
I would start by reporting this to Intel. No doubt, they will not resolve it by the end of the week, but eventually. In the mean time, I'd also report it to Qt software, so see if they can trouble shoot it as well.
In the mean time, you know the issue and how to resolve it (no OpenGL screensavers). So all you have to do is to inform your customers. The best would be if the application itself could inform the customers, but detecting if a screensaver uses OpenGL or not does not seem feasable.
Perhaps you could do some additional tests. For instance, what happens if your application is run in paralell with, say, Google Earth in OpenGL mode?

AviSaveOptions() dialog window is distorted!

I'm using windows XP , hebrew version.
I am trying to save an AVI file using the Video For Windows API in C++, when I run the AviSaveOptions() function, the dialog opens as a thin unclickable strip at the corner of the screen.
Would it have anything to do with the language (Hebrew)? maybe with the vfw driver itself? what might cause a windows dialog window to be distorted/invisible?
thanks
Roey
Can't really answer your question, but I've seen problems with localized versions of AVISaveOptions dialog. The Swedish Windows XP version of it never showed but one codec, although more were installed on the system. Verified on several Swedish XP installations. Other languages we could test didn't show this. Submitted a bug report to MS, and to my great surprise, never heard back.
The AVIFile API in general seems to be spec'ed and and implemented by a bunch of drunken monkeys, so I wouldn't be hugely surprised if they had botched the Hebrew version beyond recognition.
I've seen a similar distortion of the AVISaveOptions dialog, only with Windows 7 Ultimate (English) with the Arabic language pack installed and the display language set to Arabic.
For me the workaround was setting the uiFlags parameter to ICMF_CHOOSE_PREVIEW, check the AVISaveOptions documentation. Not an ideal solution if you don't want the preview functionality on the dialog, but at least it is visible and displayed correctly.