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

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.

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

[font="Tahoma"]In my opinion your best bet is to get in front these issues yourself and get closer to the metal. [/font]

[font="Tahoma"]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.[/font]

[font="Tahoma"]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.
[/font]

[font="Tahoma"]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.[/font]

[font="Tahoma"]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.[/font]

[font="Tahoma"]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.[/font]



[font="Tahoma"]Anyway, here are a few links to get you started if you don’t already have these resources: (tons more out there)[/font]

[font="Tahoma"]WinDBG [/font][font="Tahoma"]http://msdn.microsoft.com/en-us/windows/hardware/gg463009[/font]

[font="Tahoma"]Process Explorer [/font][font="Tahoma"]http://technet.micro...ernals/bb896653[/font]

[font="Tahoma"]Setting up WinDBG [/font][font="Tahoma"]http://msdn.microsoft.com/en-us/windows/hardware/gg462988[/font]

[font="Tahoma"]How to Analyze Crash dump files [/font][font="Tahoma"]http://www.codeproject.com/KB/debug/Crashes.aspx[/font]



[font="Tahoma"]*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)[/font]

[font="Tahoma"]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 [/font][font="Tahoma"]http://support.microsoft.com/kb/315263[/font]

[font="Tahoma"] Hope this helps you man...[/font] [font="Tahoma"]Good luck and happy hex hunting [/font]