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.
Related
I need some help in detecting lock screen from a custom credential provider running on Windows 10. I believe Windows doesn't provide any APIs to detect lock screen presence. I'm currently using UI Automation to detect lock screen on Windows 8.1. However, it's not working on Windows 10. Any help would be appreciated.
We are having some weird problems using Java3D over a Windows' remote desktop. The remote machine is a virtualized server, which can't use the (physical) server's graphic card. When I run the app, the following error pops:
Unable to create DirectX D3D context.
Neither Hardware and Software Renderer are available.
Please update your video card drivers
and get the latest DirectX available at http://microsoft.com/directx
After switching to OpenGL (starting the JVM with -Dj3d.rend=ogl) the same error appears! What is possibly happening? How can I fallback to software rendering, either with OpenGL or DirectX, when the error appears?
EDIT: I've already tried using another OpenGL vendor, using Mesa3D's DLLs instead of the native ones, but it did nothing different. I also installed DirectX SDK and tried to start Java3D with the reference driver (-Dj3d.d3ddevice=reference), but it didn't work either.
The same error appears because if OpenGL fails, Java3D tries to use DirectX. If that fails, too, then the pop is shown.
I didn't manage to solve it because, instead of trying to change things at the remote server, I tried to emulate the problem at my own machine by disabling the video driver. I still don't know why both problems aren't equivalent, but after I returned to work on the server and put DirectX's d3dref9.dll at Java's \bin, it worked.
Now I have an entire new problem, as the JVM can't find the DLL if I place it at java.library.path or Tomcat's \bin :) Problems just can't not exist.
Try the following:
Under Windows:
First, open the Display Properties pane by right clicking on desktop screen and choosing Properties item in menu. In that pane, display the Settings tab, and click on the Advanced button. Then in the Troubleshoot tab of the pane that opened, check the Hardware acceleration cursor is at its maximum on Full, confirm your choice and try to run your program again.
If the previous operation didn't resolve your problem, update the OpenGL and DirectX drivers of your graphic card with the latest available ones, and try to run Sweet Home 3D again.
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.
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
How to disable ctrl+alt+del using C in Window OS? I tried
SystemParametersInfo(SPI_SETSCREENSAVERRUNNING, true, &bOldState, 0);
but it doesn't working for me. Can you kindly guide me, so that I can make it possible.
The SPI_SETSCREENSAVERRUNNING parameter you are using is designed for screensavers on Windows 95. It works on Windows 95/98/ME and earlier. It does not work on Windows NT/2000/XP/Vista.
The Ctrl-Alt-Del Hotkey combo can be disabled on Windows NT/2000/XP/Vista, but not usually from an application (user mode). Here are the mechanisms I'm familiar with.
I haven't tried it on Windows 7, but I'm sure some or all of these techniques still work there.
A GINA DLL can intercept the CAD sequence, but that may be overkill. It works because Windows registers the CAD Hotkey and sends a callback to GINA DLL to handle the action when you press it. A replacement GINA DLL can handle the callback differently (ignoring it), but it may be tricky to do this and remain compatible with other login mechanisms using other custom GINA DLLs.
You can write a keyboard driver to intercept it. There is pretty good free source code on the net for it if you search for it. Look for the Ctrl2Cap driver and similar things. (This driver remaps the Caps Lock key and Ctrl keys to mimic old keyboard layouts.)
You may also be able to "remap" keys in the registry to achieve your goal using the Scan Code Mapper. They added this in Windows 2000. It's limited, but workable in some situations. See this MSDN page for details. Pay attention to the limitations, though. For example, it requires a reboot for the change to take effect.
Finally, you can disable the Task Manager and other features through an administrative setting using the Windows Admin Toolkit. It still interrupts everything to show you a "You can't do that" dialog. But at least it works to limit users' access to the machine.
I wrote a device driver (option 2 on my list above) to block Ctrl-Alt-Del for Windows 95/98 (13 years ago), and later for Windows NT/2000/XP. I sold a lot of those. They're still around if you look.
Are you attempting to disable the requirement of ctrlaltdelete for login, or are you trying to disable the hotkey entirely? I don't believe the latter is even possible; it's a built-in OS-level override designed to circumvent any user-level program.
With Windows XP you can write a GINA DLL to do this. Windows 7 doesn't seem to have a GINA DLL anymore though. There may be some sort of policy setting to accomplish the same, but if so I haven't seen it documented.
Ctrl-Alt-Del is the Secure Attention Sequence. The goal is to let the user communicate securely with the OS. It can't be disabled by programs, by design - it would no longer be secure in that case.