When faced with a crashing process or application, the following procedure is one way to obtain useful information regarding the specifics of the crash, and hence the likely cause:
1) Download and install either the 32-bit or the 64-bit "Debugging Tools" package, depending on your OS type: Debugging Tools for Windows - Overview
2) Open a CMD prompt and CD to the folder where you installed the debugging tools.
3) Run this command after substituting the real executable name for <ProcessName> in the example: cscript adplus.vbs -crash -nodumponfirst -minionsecond -quiet -pn <ProcessName>.exe
4) Reproduce the application/process crash.
5) Find the new folder in that same location with a DMP (memory dump) file.
In that dump folder you should find 2 DMP files:
a) A massive one (hundreds of MB) with "1st_chance" as part of its name.
b) A much smaller one (few MB at most) with "2nd_chance" in the name.
It's (b) that is of primary interest. Zipped up, that file may only be a few hundred KB in size - small enough to upload here.
================================= Background Information:
Unlike a BSOD, a crash in a non-critical process does not normally affect the rest of the operating system (OS). Instead, once the OS notices that the process has attempted to do something undesirable or impossible, such as accessing memory which does not belong to it or attempting to divide by zero due to programming bugs, the offending process is shut down to prevent further damage.
To the user, this looks like an application crash, although in more recent versions of Windows the wording in the user interface has been softened to refer to an application as having "stopped working". The event logs will frequently record some summary information about the crash conditions, but unless a 3rd-party module (usually a DLL) is specifically fingered by the event description, it is difficult to proceed based on the event information alone.
By attaching a debugger to the process using the steps above, a crash can be "recorded" in the sense that a memory dump is produced which contains far more information than the textual event description. Analysis of the memory dump using techniques similar to those employed during BSOD troubleshooting can frequently pinpoint the cause of the application crash.