Sign in to follow this  
cyberrex

Using D3D9 proxy DLL to enable window mode crashes games

Recommended Posts

cyberrex    122
Hi, I've been trying to write a D3D9 proxy DLL that enables any game to run in window mode. In particular I'm interested in running CnC 3 (Demo, for now) windowed. So far I've had limited success, possibly because I don't know much about D3D programming. ;) I tried two other games WoW (works fine) and X³ (doesn't work). Debugging CnC3 isn't that easy because CNC3Demo.exe launches DemoGame.dat which appears to be the actual game but of course the debugger only attaches itself to the exe and not to the child process. Getting to the problem: I'm hooking two functions, CreateDevice and Reset, adding the following code.
	pPresentationParameters->Windowed = TRUE;
	pPresentationParameters->BackBufferWidth = 0;
	pPresentationParameters->BackBufferHeight = 0;
	pPresentationParameters->FullScreen_RefreshRateInHz = 0;
In addition to the above code I'm setting several window styles to get a border, title bar, buttons, system menu, etc. If I start debugging the game launches in window mode, as expected, but when it loses focus (e.g. by clicking on VS) it simply crashes. My best guess is that CnC 3 handles WM_ACTIVATE and does something that is not allowed in window mode. There is another issue with the mouse position. The cursor position registered by the game is off (cursor needs to be SE of a button to activate it) but I have some ideas to work arround that so let's concentrate on the other one first. I'm running Windows Vista, Visual Studio 2005 SP1 + Vista update and I'm certain the proxy DLL itself is working fine. I believe I've said everything so ... what do you think? I appreciate any insight or ideas you might have. Best regards, cyberrex

Share this post


Link to post
Share on other sites
TheAdmiral    1122
A few things spring to mind, but it'll take some further investigation.

A full-screen app obviously treats its device differently to a windowed one. Trying to hack a windowed-mode app into working full-screen would be nigh on impossible, but the converse seems quite doable. I can only think of two primary sources of this problem:

The graphics device should behave well in windowed mode, provided the application is coded accordingly. Changing window focus shouldn't trigger any OnLostDevice events, so I'd only imagine the allergic reaction would be caused by the WM_KILLFOCUS message. Perhaps it would be worth hooking this message to investigate the behaviour.

Slightly less predictable are the input devices. If things are being done via Windows messages, then this is a non-issue. But if the target app is using DirectInput (you could check the PE's import table) then there may be trouble. If I were writing an app that's designed to run only in full-screen, then I would have my keyboard and mouse devices acquire exclusively, and wouldn't be concerned with losing them unless I anticipate alt-tabbing. Simply trying to gain exclusive access to an input device from windowed mode sounds like a bad idea.

Of course, these are just a couple of the possibilities. If I were you, I'd get hold of a decent user-mode debugger (I keep recommending OllyDbg) and find out exactly which function is causing the crash.

So I charge you with the task of finding out which function (be it an API or user-code) is causing the crash. Once that's concluded, we can think about fixing things.

Admiral

Share this post


Link to post
Share on other sites
cyberrex    122
I tried debugging it using OllyDbg, but again the debugger only attaches to the launcher (CNC3Demo.exe) and not to the actual game (DemoGame.dat), which I can't start directly. I also hooked WM_KILLFOCUS, as you suggested, and determined that the app crashes before WM_KILLFOCUS.
Any more ideas?

cyberrex

Share this post


Link to post
Share on other sites
TheAdmiral    1122
It's likely that CNC3Demo is launching DemoGame manually. You could set a break on the usual suspects, such as CreateProcessA, but it may be more productive if you take advantage of Windows's JIT (just-in-time) debugging.

From OllyDbg, (options menu), tell it to set itself as the system's JIT debugger. Now, when an application crashes, you'll be prompted with the usual unhandled exception dialog, but you'll have the option to debug. From here, OllyDbg will attach to the terminal process, and you'll be able to investigate the call stack to get some more clues as to what went wrong.

Admiral

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this