First of all, that error is not your fault.
Some programmer forgot to handle some error in his program, so it fails.
Of course, the problem doesn't have to be in the application itself (so the programmer is off the hook). It could be in Windows or it could be in the MSVC runtime, or the .Net runtime or your video card drivers or whatever (which is why you're always told to install all updates before contacting support).
So you got all that covered, but the problem persists. What now?
Well, now the only thing left is that the application in question is faulty and the programmer is no off the hook for this one (A-HA!). So it's the problem of the author of the software. So contact them and ask them if they could help you out and fix this issue.
But what if they tell me their software is perfect, I'm the only one with that issue and generally, it's my fault?
Now comes the fun part. You get to find the actual cause of your error message.
What did the application actually tell the operating system that made the operating system go "You need to shut yourself the f- down!"?
To do so, you have many tools at your disposal.
- Log files
- The Windows event log
- Process Monitor
Should the application in question write out any log files, those can be gold in search for the cause of your application issue. Read them and discuss possible error messages here.
The Windows event log will surely contain some information about the crashed application. If it is actually a .Net application, you might even get lucky and might be able to pull a call stack from the log (which would be very helpful for developers).
If all else fails, turn to Process Monitor. Process Monitor is a tool that logs all communication between an application and the operating system (so to speak). So in the resulting, captured data, you could see exactly what function the application called that resulted in the unhandled error condition. This could be something trivial like trying to access a non-existent file or registry object. But finding that one call on the log can takes ages and if you have no experience with software development, you'll most likely not get very far with this approach.
If that makes you go "Well, that's pretty unlikely to help me solve my issue.", then you're probably right. While it can be fun to try and track down an issue like this for certain people, it's usually the job of the person who wrote the faulting software.
They are far better equipped to find the problem than you are. A proper bug report can go a long way sometimes.