Elegant Crash in DirectX

Steven J. Morris

unread,

Nov 27, 1996, 3:00:00 AM11/27/96

to

Hope I'm posting to the right place. Does anyone
know a way to elegantly crash in Win95 with DirectX
running? I find that when my app crashes (Release version)
while having control of the screen, the user has to
reboot to get his/her screen back.

Is there a way to cast and catch an exception which leads
to a code fragment for closing down directx?

Thanks,
Steven

--
Steven J. Morris <mor...@roz.mer.utexas.edu>
Homepage: http://ccwf.cc.utexas.edu/~morris/

Aaron Wieland

unread,

Nov 27, 1996, 3:00:00 AM11/27/96

to

I'm not familiar with programming Windows apps in C++, but here is a
code fragment from _Delphi 2 Unleashed_:

procedure TForm1.ExceptionHandler( Sender: TObject; E: Exception );
begin
if Assigned( DirectDraw ) then DirectDraw.FlipToGDISurface;
MessageDlg( E.Message, mtError, [ mbOK ], 0 );
end;

The exception handler is installed with
Application.OnException := ExceptionHander;

Since C++ supports exception-handling, it should be possible to adapt
this example. In your case, you would add a call to
IDirectDraw::Release().

Tim Sweeney

unread,

Nov 28, 1996, 3:00:00 AM11/28/96

to

> Hope I'm posting to the right place. Does anyone
> know a way to elegantly crash in Win95 with DirectX
> running? I find that when my app crashes (Release version)
> while having control of the screen, the user has to
> reboot to get his/her screen back.
>
> Is there a way to cast and catch an exception which leads
> to a code fragment for closing down directx?

void main(void)
{
// Set up DirectX here and go into fullscreen mode.
try
{
// Call your game here.
}
catch(...)
{
}
// Shut down DirectX here.
}

This will catch most problems. Crashes that are due to calling DirectX with
invalid parameters, and some
other hairy system level Win95 crashes, won't recover this way, but the
above is the best that one can do in Win95.

-Tim

Derek Taylor

unread,

Dec 2, 1996, 3:00:00 AM12/2/96

to

Are you using DX2? I think 3 puts the resolution back for you.

Jason Shankel

unread,

Dec 4, 1996, 3:00:00 AM12/4/96

to

In article <01bbe0a1$becec900$4fd4...@derekt.edmark.com>, der...@edmark.com
says...

Yes, this indeed does happen. Under DX3 it happens less often, but
it still happens.
The reason is that, while a buffer is locked, DX3 grabs control of the
WIN16MUTEX which is used to synchronize control of GDI, USER and KERNAL
between 32-bit apps and 16-bit apps running in the 16-bit VMM. As long
as a subsystem has control of this mutex, no one else can render to the
screen.
This is why you cannot debug with a GDI debugger (like MSVC) between the
lock/unlock pairs.
The solution is to do as little as possible between lock and unlock to avoid
crashes. Unfortunately, with D3D, this is not always in your hands.

Get used to rebooting, just like the good ole win16 days.

Igor Laera

unread,

Dec 10, 1996, 3:00:00 AM12/10/96

to

On 4 Dec 1996 00:03:58 GMT,
sha...@crl.com.___.no.automatic.list.generators (Jason Shankel)
wrote:

>This is why you cannot debug with a GDI debugger (like MSVC) between the
>lock/unlock pairs.
>The solution is to do as little as possible between lock and unlock to avoid
>crashes. Unfortunately, with D3D, this is not always in your hands.

I'm would suggest to "debug" it over a serial terminal or network; by
an attached computer. My old DX486/100 with a lousy dos terminal eats
the output, and - when you need - input.

It can save *weeks* in coding, if you can change significant variables
on the fly (and if your code support this). You haven't to worry about
speed/display quirks, since the whole "debug screen" is on a different
cpu.

bye
Igor