Jump to content

  • Log In with Google      Sign In   
  • 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.

  • You cannot reply to this topic
11 replies to this topic

#1 Malmodir   Members   -  Reputation: 102

Like
0Likes
Like

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)

Sponsor:

#2 programci_84   Members   -  Reputation: 335

Like
1Likes
Like

Posted 10 May 2011 - 11:22 PM

Sorry, I don't have any time to download and test your app.

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.

#3 Malmodir   Members   -  Reputation: 102

Like
0Likes
Like

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?

#4 JBourrie   Members   -  Reputation: 1204

Like
0Likes
Like

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:

http://www.smashanddashgame.com/


#5 programci_84   Members   -  Reputation: 335

Like
0Likes
Like

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.

#6 GregMichael   Members   -  Reputation: 143

Like
0Likes
Like

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.

#7 a_insomniac   GDNet+   -  Reputation: 611

Like
1Likes
Like

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)

WinDBG http://msdn.microsoft.com/en-us/windows/hardware/gg463009

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 Posted Image

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

Electrical Engineering Student
http://ibendwires.com


#8 Malmodir   Members   -  Reputation: 102

Like
0Likes
Like

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;

	if(d3d->GetAdapterDisplayMode(D3DADAPTER_DEFAULT, &d3ddm) < 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.SwapEffect = D3DSWAPEFFECT_DISCARD;
	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();
		myGame.Init(myDirectX.device); ////////// display first frames (loading screen) and initialize resources

    	///////// --> 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
* The first access to the device happens (setting default matrices)
* The next step is loading everything (loading xact with resources, direct input stuff, ......, creating a render target for the full screen quad, lastly drawing the shadow map)
Because each of the loading steps requires a time, the loading screen would at least show itself...?


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.


#9 Malmodir   Members   -  Reputation: 102

Like
0Likes
Like

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...

https://rapidshare.com/files/545853980/LoadingScreen.zip
https://rapidshare.com/files/821660404/LoadingScreen-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.

#10 marius1930   Members   -  Reputation: 119

Like
0Likes
Like

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...adingScreen.zip
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.

#11 MickeyMouse   Members   -  Reputation: 201

Like
0Likes
Like

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
my blog | my games

#12 Malmodir   Members   -  Reputation: 102

Like
0Likes
Like

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.



PARTNERS