Just to note, I am not a programmer by trade. Hobbiest at a stretch.

We are forced to use VS2008 as our code is from early 2000s.
Many users of our application are getting the following error in Event Log.

Faulting module name: MSVCR90.dll, version: 9.0.30729.9619, time stamp: 0x5c4bd872
Exception code: 0xc0000417 
Fault offset: 0x000532cd
Faulting process ID: 0x47d0
Faulting application start time: 0x01d5ba26ae5225eb
Faulting application path: C:\Program Files (x86)\Steam\steamapps\common\game\game. exe
Faulting module path: C:\WINDOWS\WinSxS\x86_microsoft .vc90. crt_1fc8b3b9a1e18e3b_9. 0. 30729. 9619_none_508d9c7abcbd32b6\MSVCR90. dll
Report ID: 7f76a236-78fd-4c15-adaf-9df03438f5dd
Faulting package full name: 
Faulting package-relative application ID: 

They have "Microsoft Visual C++ 2008 Redistributable Package (x86)" installed.

I have been unable to replicate it my end. Even with machines without the redistributable, they work,

Any ideas?

Exception code: 0xc0000417 
Fault offset: 0x000532cd

That exception code is probably the error STATUS_INVALID_CRUNTIME_PARAMETER, meaning something in the code called a function with a bad parameter. The board's automatic formatting might mess that up, those are the words "STATUS INVALID CRUNTIME PARAMETER" separated with underscores. You can see more about it from your favorite web search engine.

The easiest option is to get a crash dump from the crashing computer, and open it up on Visual Studio. The system will prompt you to locate the debug information, normally kept in a .pdb file. You need to have exactly the same build, which includes all the critical debug information such as data mapping from source code to compiled executable. With any luck the crash dump will stop directly on the function call with the wrong parameter, although it might also happen to be deeper in the stack at a function your code called, or somewhere else like inside a crash handler.

If you don't have a crash dump file, you can use the same debug data, or use a disassembled version of your program in conjunction with the debug data, to find out what it at the location 0x000532cd when it crashed. Unlike the crash dump, if you are not directly on the offending function call, perhaps either inside another function or inside a crash handler, the location will be useless.

If you don't have the original debug data (likely a .pdb file) and the original source code, the task to hunt down the problem is far to advanced for a general post here.

@frob Thank you for the info. Never thought to use the crash dumps.

We obfuscate our code, will that cause issue with crash dumps?

So normal crashes create the dump file but for these users, no dump file is being made.

Even with SmartAssembly, it does not create the dialog to send dump file.

Since you cannot reproduce it, and you cannot get a good stack dump, that puts you in a bad spot.

You can attempt to fix it, but you'll be doing it blind, with know actual knowledge of if you are addressing the crash.

I'd recommend your next step is to get a proper stack dump. Not only will it help in this case, but help with future bugs, too.

One thing that might be worth trying is to gather detailed system info from the users that are having the problem. Maybe you'll spot some commonality that will give you an idea of how to reproduce it. I'd suggest gathering:

• All of the settings for the game itself.
• Hardware and driver info (a dxdiag report is a good start).
• The version and language of Windows they are running (dxdiag will cover that too).
• A list of other processes running at the same time as your game (and maybe all installed software). There's a chance that other software can cause compatibility issues - antivirus programs for example.

If you spot some commonality, then try to set up a PC / Virtual Machine of a similar spec to try to reproduce the problem yourself.

You could also ask a user to configure Windows to capture crash dumps for you if your own crash reporting isn't working. There's some registry settings you can change to enable that: https://docs.microsoft.com/en-gb/windows/win32/wer/collecting-user-mode-dumps?redirectedfrom=MSDN