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

Question

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?

Neveda

wow. I didn't know that'll happen. will be following this question. – Spectre

Why on earth would you want to run the app without explorer anyway? Even in a kiosk, if you want full screen, then write a full screen app. Don't kill the shell! – Trimester

For the record it sounds like you're depending on some application (typically a graphics driver) which is waiting for an explorer hook. (such as the graphics right click menu some vendors attach to the desktop right click menu) No explorer == that doesn't load, and the graphics driver chokes. Maybe. But I really doubt it. How are you "tweaking" the startup process exactly? – Trimester

@Billy: Not my decision. I was told it was because of security reasons (don't let users touch the file system directly, for example). I know, that can be done using security policies, but the higher spheres decided on this. – Neveda

@dario_ramos: Then whoever told you to do that is a complete idiot. Disabling explorer doesn't make the system any more secure. After all, all someone has to do is launch cmd, or start a copy of xplorer2, or similar. Users can touch the filesystem whether you let them or not. – Trimester

I think it is a perfectly reasonable idea to not want explorer or any other GUI process running if it is not needed. Please stop bitching around, these comments are also not helpful to find an answer to the question. – Julesjuley

Answer 1

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.

Neveda

Good catch. And thanks for actually posting the solution for future searchers. – Noonday