• Create Account

## [DX9] Game crashing on other computers

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

11 replies to this topic

### #1Malmodir  Members

Posted 10 May 2011 - 10:55 PM

Hi there,

I have to deploy my game to several other machines, but it crashes right after its start. I do not check for success after every usage of DX functions, so I cannot estimate where the problem might be. I for myself have a fairly new laptop meeting more than basic requirements. The problem is that I don't know which are common problems I have to watch out for?

My configuration:
Win 7
i7, Geforce 445M GT (3GB), 4 GB RAM
Latest video drivers and DX redistributable, DX SDK

Sample target configuration:
Win XP SP3
Core2Duo 2 GHz, Intel GMA X3100, 3 GB RAM
Latest video drivers and DX redistributable

Environment:
* Resources of course deployed
* Build in release mode
* Switched the debug DLLs to retail ones
* Occurences of non-power-2 Textures
* Several render targets (XARGB32, R32F)
* Shader Model 2.0 at maximum
* Window mode with fixed resolution of 1280*720
* ~1.500.000 triangles rendered per frame (back buffer, less in shadow map and depth map)

As I have no access to a lower machine I cannot test it by myself and have to ask friends, which of course becomes very annoying for both of us. 7 out of 10 could start the game instantly, the rest encountered crashes right after start (before loading screen, that is before even creating the render targets and textures (???)).

If you are willing to test it, the link is: https://rapidshare.c.../TribalWars.zip (traffic shared, so full speed)

### #2programci_84  Members

Posted 10 May 2011 - 11:22 PM

But the only thing I can say is this: Check for all device types (HAL or REF), render target and/or adapter formats (XRGB8, ARGB8, R5G6B5 and other 16- or 32- bit FP formats etc.) and vertex processing types (Hardware or Software) before you create your D3D Device. Because, for example, on your machine, you can create a HAL D3D device with Hardware Vertex Processing; but other machine(s) may support only software vertex processing. If so, it's so normal for application to crash.

IDirect3D9 interface has a lot of useful methods to test'em: CheckDeviceFormat(), CheckAdapterFormat(), EnumAdapterModes() etc.

hth.
-R
There's no "hard", and "the impossible" takes just a little time.

### #3Malmodir  Members

Posted 10 May 2011 - 11:48 PM

Thank you.

I added a few checks in the initialization routine and will pick someone to test it again. I will report back in the next hours.
Are there any other things to take care of? Having updated the directx runtimes since the last 2 months should suffice?

### #4JBourrie  Members

Posted 11 May 2011 - 12:49 AM

Thank you.

I added a few checks in the initialization routine and will pick someone to test it again. I will report back in the next hours.
Are there any other things to take care of? Having updated the directx runtimes since the last 2 months should suffice?

If adding DirectX debugging doesn't find the error, search Google for "depends.exe" (Dependency Walker). If you open any executable in it, it will tell you any dependencies (like DLL files) that might be missing. I've found this to be very helpful in tracking down compatibility issues.

Check out my new game Smash and Dash at:

### #5programci_84  Members

Posted 11 May 2011 - 07:20 AM

... Are there any other things to take care of? Having updated the directx runtimes since the last 2 months should suffice?

Yeah porting latest DirectX runtimes may help; but I also have something to add: You know DirectX functions return an HRESULT value. So you can check whether they fail or not and do something.

For example:
HRESULT hrD = pD3D->CreateDevice ( ... );
if (FAILED(hrD))
{
MessageBox (0, "Failed to create D3D Device. App. will now exit.", "D3D Error", MB_ICONHAND);
//exit directly or jump somewhere you want.
}

This kind of codes will help you to find where the error is. You can use wherever you want.

hth.
-R
There's no "hard", and "the impossible" takes just a little time.

### #6GregMichael  Members

Posted 11 May 2011 - 07:27 AM

" I do not check for success after every usage of DX functions, so I cannot estimate where the problem might be"

Fix that and you should narrow down where the problem is.

### #7a_insomniac  GDNet+

Posted 11 May 2011 - 08:10 AM

In my opinion your best bet is to get in front these issues yourself and get closer to the metal.

Sooner or later everyone one of us dabbling in game development needs to get a handle on (3) things very well. Hard core low level debugging, reading ASM code and Crash Dump analysis….it’s truly imperative to master these to a degree in order to limit frustration such as which you are having.

To start I would make sure that each game tester at least has a copy of “Process Explorer”. This will allow for them to provide you with crash dump files. When a tester runs your application and it crashes, make sure they don’t close the dialog box yet. Bring up Process Explorer and right click on your game.exe then export out either a Full or Mini dump file. Get yourself and FTP server or something similar and have them send that .dmp file to you.

Once received, you should already have your environment tailored to be pulling down symbols from the symbol store…if not I’d look into how to set this up (easy). This will require you to have a copy of WinDBG installed and configured. Using WinDBG is the best way to interrogate dump files.

If your symbol path is setup properly, WinDBG and know enough ASM and Hex to be dangerous…you will know why your apps are crashing in no time at all.

One of the early posters above brought up "DependencyWalker" which is another cool tool but may not provide the smoking gun in this case. The error message received would have indicated a dependency was missing; in your casing it appears something is causing your app to crash. In any event, depending on what build you provided for testing, make sure that your testers at least have 2005,2008 or 2010 C++ redistributable installed (whatever you are developing with) because the runtimes could be missing on their machines…again this all comes down to how you may have built the exe.

Anyway, here are a few links to get you started if you don’t already have these resources: (tons more out there)

Process Explorer http://technet.micro...ernals/bb896653

Setting up WinDBG http://msdn.microsoft.com/en-us/windows/hardware/gg462988

How to Analyze Crash dump files http://www.codeproject.com/KB/debug/Crashes.aspx

*If you can’t get a full dump file from your testers (usually because they can weigh in as much as several hundred megs to a few gigs)

Here is an article that shows you how to go about reading mini dumps…not as much info in a mini but it just may help in some cases…some of the same tools required though http://support.microsoft.com/kb/315263

Hope this helps you man... Good luck and happy hex hunting

----------
Coder and 3D Artist

Electrical Engineering Student
http://ibendwires.com

### #8Malmodir  Members

Posted 11 May 2011 - 08:49 AM

As I said, I added some basic checks recently and had someone test it again. I'll just pass the initialization code down here, but the MessageBoxes are not being triggered...

DirectX Initialization:
int DirectX::Init(HWND window, bool fullscreen, int fsaa, int width, int height)
{
hWnd = window;
D3DDISPLAYMODE d3ddm;
D3DDEVTYPE devtype;
D3DCAPS9 caps;

d3d = Direct3DCreate9(D3D_SDK_VERSION);
if(!d3d)
return 0;

return 0;

D3DMULTISAMPLE_TYPE fstype = D3DMULTISAMPLE_NONE;
if (fsaa == 2)
fstype = D3DMULTISAMPLE_2_SAMPLES;
else if (fsaa == 4)
fstype = D3DMULTISAMPLE_4_SAMPLES;
else if (fsaa == 8)
fstype = D3DMULTISAMPLE_8_SAMPLES;

ZeroMemory( &d3dpp, sizeof(d3dpp));
d3dpp.Windowed = !fullscreen;
d3dpp.MultiSampleType = fstype;
d3dpp.BackBufferWidth  = width;
d3dpp.BackBufferHeight = height;
d3dpp.EnableAutoDepthStencil = TRUE;
d3dpp.AutoDepthStencilFormat = D3DFMT_D24S8;
d3dpp.BackBufferFormat = D3DFMT_X8R8G8B8;
d3dpp.PresentationInterval = D3DPRESENT_INTERVAL_ONE;

if (d3d->GetDeviceCaps(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, &caps) < 0)
{
MessageBox(window, "No HAL-Device - might be sloooooow!", "Notification", MB_OK | MB_ICONWARNING | MB_SETFOREGROUND);
devtype = D3DDEVTYPE_REF;
}
else
devtype = D3DDEVTYPE_HAL;

if (d3d->CreateDevice(D3DADAPTER_DEFAULT, devtype, window, D3DCREATE_HARDWARE_VERTEXPROCESSING, &d3dpp, &device) < 0)
if (d3d->CreateDevice(D3DADAPTER_DEFAULT, devtype, window, D3DCREATE_HARDWARE_VERTEXPROCESSING, &d3dpp, &device) < 0) // retry
{
MessageBox(window, "No Hardware Vertex-Processing!", "Notification", MB_OK | MB_ICONWARNING | MB_SETFOREGROUND);
return 0;
}

HRESULT hr;
hr = d3d->CheckDeviceFormat(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, D3DFMT_X8R8G8B8, D3DUSAGE_DEPTHSTENCIL, D3DRTYPE_SURFACE, D3DFMT_D24S8);
if (FAILED(hr))
{
MessageBox(window, "No fitting Depth/Stencil Format!", "Notification", MB_OK | MB_ICONWARNING | MB_SETFOREGROUND);
return 0;
}

hr = d3d->CheckDeviceFormat(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, D3DFMT_X8R8G8B8, D3DUSAGE_RENDERTARGET, D3DRTYPE_TEXTURE, D3DFMT_R32F);
if (FAILED(hr))
{
MessageBox(window, "No Single-Precision Render Target!", "Notification", MB_OK | MB_ICONWARNING | MB_SETFOREGROUND);
return 0;
}

return 1;
}

Application Entry Point:
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPreviousInstance, LPSTR lpcmdline, int nCmdShow)
{
HWND hWindow;
Console console; /////// manual console allocation
console.Open(); //////// redirection of io-streams to new console

hWindow = NewWindow(VIDEO_WINDOWTITLE, 0, 0, VIDEO_SCREENWIDTH, VIDEO_SCREENHEIGHT); //////// window creation
if (GetConsoleWindow() == NULL || hWindow == NULL)
{
MessageBox(NULL, "Window or Console creation failed!", "Notification", MB_OK | MB_ICONWARNING | MB_SETFOREGROUND);
return 0;
}
MoveWindow(GetConsoleWindow(), 1, 1, 600, 400, true);

SetTimer(hWindow, 0, TIMER_MS, NULL);
ShowWindow(hWindow, nCmdShow);

// Init our game
int bi = myDirectX.Init(hWindow, VIDEO_FULLSCREEN, VIDEO_ANTIALIASING, VIDEO_SCREENWIDTH, VIDEO_SCREENHEIGHT); ////////// above routine
if (bi)
{
myDirectX.hInst = hInstance;
myDirectX.Project();

///////// --> enter message loop
}
/////////// clean up


Now as I recall this might be the point to deliever. Obviously no check fails and I don't know other causes. :/
Trying to deduct some facts:
* The window is being created
* The device is being created
* Several capabilities are present

Edit:
Had this written concurrently to the last reply. I appreciate the effort and will of course take a look, but I will post this anyway for short. Maybe there are some tips on a higher level, which I can maintain meanwhile.

### #9Malmodir  Members

Posted 13 May 2011 - 12:57 PM

Sooo, I stripped down my whole code to the basic initialization stuff. Still it does not work on chosen machines, even though it just displays a 2D string without loading anything...

Both trafficshared and less than 20 KB in size.

I really don't know what is going on and presentation is next month, so any help is considerably appreciated.

### #10marius1930  Members

Posted 16 May 2011 - 12:52 PM

Sooo, I stripped down my whole code to the basic initialization stuff. Still it does not work on chosen machines, even though it just displays a 2D string without loading anything...

https://rapidshare.c...gScreen-src.zip
Both trafficshared and less than 20 KB in size.

I really don't know what is going on and presentation is next month, so any help is considerably appreciated.

Direct3D9: (INFO) :======================= Hal HWVP device selected
Direct3D9: (INFO) :HalDevice Driver Style b
Direct3D9: :BackBufferCount not specified, considered default 1
Direct3D9: :DoneExclusiveMode
Direct3D9: (INFO) :Using FF to VS converter
Direct3D9: (INFO) :Using FF to PS converter
D3D9 Helper: Warning: Default value for D3DRS_POINTSIZE_MAX is 2.19902e+012f, not 6.16272e-317f. This is ok.
Direct3D9: (WARN) :Ignoring redundant SetRenderState - 8
Direct3D9: (WARN) :Ignoring redundant SetRenderState - 8

Runs fine and exits cleanly, i'll try it on my weaker laptop later, see if anything pops up

Edit: Tested on my U31f, runs fine.

### #11MickeyMouse  Members

Posted 16 May 2011 - 11:12 PM

I bet it wouldn't take much of your time (probably less than 1 hr) to put macro like this around every Win32 / DX call that returns HRESULT:

#define CHECK_HR(op) \
{ \
HRESULT hr = (op); \
if (FAILED(op)) \
{ \
char buffer[1024]; \
sprint(buffer, "Operation %s failed in %s:%d, hr = 0x%x", #op, __FILE__, __LINE__, hr); \
ShowMessageBox(NULL, buffer, "Error", MB_INFO); \
} \
}

Maciej Sawitus

### #12Malmodir  Members

Posted 22 May 2011 - 04:41 AM

Oh, I did not notice any further replies, but yes the problem still exists...

I enclosed every single usage of the D3DX-functions with a similar macro after adding other stuff. The features are growing and it gets the shape of a usable game, still it runs only on few machines.
My prof gave me some extra time (2 weeks from now), because other course participants reached their goals by lowering target requirements (no shaders, easy up game mechanics).

@marius1930:
This is the reason I cant do any more assumptions for my problem. I increased the warning level, stripped out everything unneeded, let my testers update directx, install xna runtime and run the caps-viewer. Some report they don't even see the console open up, other's do. It's like a random crashomizer.

I'll try to get my hands on one of the issued computers to start an analysis (referring to a_insomniac), but this may take a while.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.