VOGONS

Search

Common searches

Host machine unresponsive when debugging

Topic actions

First post, by reenigne

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie

I have a weird problem. I'm hoping somebody here has seen it before and/or has an idea about how to fix it.

I built DOSBox SVN in Visual Studio 2013. Not too hard, resulting binary seems to run fine. However, if the resulting DOSBox crashes or otherwise fails to process Windows messages (in particular, stopping it in the debugger causes this) the entire host machine becomes almost unusable - each keypress or mouse movement takes maybe 5-10 seconds to have an effect (which makes the mouse completely unusable and debugging impossible). The only thing I can do about it (short of power cycling the host machine) is alt+tab to a command prompt window and running "taskkill /f /im dosbox.exe" and "taskkill /f /im devenv.exe" - a tedious process which takes several minutes with the delays between each keypress.

It seems like there is some kind of global input hook in effect and Windows waits for this to timeout before processing any input messages, but I don't see any references to SetWindowsHook or similar in the source code to either DOSBox or SDL 1.2.15.

I've seen this on two different machines (both running Windows 7) so I don't think it's my mouse/keyboard/video drivers. Weirdly, if I remotely login to another machine via Remote Desktop, I can then debug DOSBox just fine on that machine.

I haven't seen this behavior debugging any other applications (on either of these machines) - what obscure Windows API is DOSBox and/or SDL using that could bring the whole machine to its knees like this?

Reply 1 of 3, by reenigne

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie

I think I've got to the bottom of this now, so I'm adding the information here in case anyone else needs it.

The call stack when the machine becomes unresponsive is:
dinput.dll!_CDIDev_Acquire@4() Unknown
SDL.dll!DX5_DInputInit(SDL_VideoDevice * this) Line 238 C
SDL.dll!DX5_CreateWindow(SDL_VideoDevice * this) Line 973 C
SDL.dll!DX5_VideoInit(SDL_VideoDevice * this, SDL_PixelFormat * vformat) Line 930 C
SDL.dll!SDL_VideoInit(const char * driver_name, unsigned int flags) Line 246 C
SDL.dll!SDL_InitSubSystem(unsigned int flags) Line 90 C
dosbox.exe!SDL_main(int argc, char * * argv) Line 1985 C++

The DInput device being acquired is the mouse.

DOSBox uses SDL 1.2 which uses DirectInput 7. According to http://www.gamedev.net/topic/550264-dinput-an … ooks-vistawin7/ there is a bug in the OS version check of DirectInput 7 on Windows 7 and Vista which causes it to think these OSes don't support raw input. DirectInput then falls back to using a global hook instead.

When a global hook is installed and the program that created the hook isn't responding (for example because it is being debugged) the OS waits for it for a while and then times out, but while it is waiting the machine's entire local input is locked (it still works fine over remote desktop).

Visual Studio installs a registry key which increases the low level hook timeout to 5 seconds (I have no idea why). Search the registry for LowLevelHooksTimeout and change the value from 5000 to 300 (ms) wherever it occurs, and reboot. This makes the machine usable (just barely) when debugging a program with a low level hook - just enough to reach the "stop debugging" button.

For now the workaround I'm using is to add "SDL_VIDEODRIVER=windib" to the IDE's debugging environment to disable DirectInput. Obviously that's not ideal if you want to debug DirectX stuff though.

The preferred fix would be to switch DOSBox to use SDL 2 instead of SDL 1.2, which would then use DirectInput 8 which apparently doesn't have this bug. Not sure how difficult this would be. If I prepared a patch to switch DOSBox to use SDL 2, is it likely that it would be accepted into SVN?

Reply 2 of 3, by NY00123

Posted on 
User metadata
Rank Member
Rank
Member
reenigne wrote:

If I prepared a patch to switch DOSBox to use SDL 2, is it likely that it would be accepted into SVN?

Just noting in case that you're ready to start working on a new patch for taking advantage of SDL2, I've already prepared one (see last post of mine with a most up-to-date patch revision): An adaptation to SDL 2.0 (Alpha-level Android build attached)

It is still an unofficial patch, though.

Go to top of page Go to top of page
Back to DOSBox Development
Close window
Close window