Windows Error Reporting

The process I am running is in a system with a process name of prowin32.exe
When a system exception occurs, that process is killed.

Over the weekend I had 42 transactions fail in a row, with a System Exception because the image it was trying to use as part of the Image Click activity was covered by a Windows Error Reporting window as below.


I’m assuming that this window is not part of the ProWin32.exe windows process, and is part of the built in Windows error handling. Does anyone know if there is a specific process I can kill to remove this window in KillAllProcesses.xaml ? Or is the only way around this to disable “Windows Error Reporting”?

@andrewjames -
This is a standard Windows Error Reporting dialog box. You can disable this in Windows.

Few questions:

  1. Do you use OpenEdge Graphical Client as part of your automation?
  2. Does this error popup at random times or after a specific action is completed in your automation flow? If you know when this happens, I think you can have the bot look for this popup and click ‘close the program’. (and open it if needed).

You can also check why this program is failing and resolve it by applying any patches required. (And if no one needs it, you can also uninstall this. :-))

1 Like

If no one is using OpenEdge, uninstall it.
Also if this is running as an add-in to office package or whatever, try disabling that.

But most importantly try to pinpoint the line of code which cause this issue. Two suggestions above will help resolve the symptoms, not the root cause.

@garuka @sreenivasm
OpenEdge is required as part of the software I am automating, and the error pops up at a random time, and isn’t something that can be replicated on demand in order to grab a selector. OpenEdge is fully up to date, but for some reason it does very occasionally crash - as long as the dialog is gone, it’s not an issue as it will only impact a single queue item.

It looks like my only option is to either disable Windows Error Reporting, or add “werfault” to the KillAllProcesses part of the framework.

I’ve opted for the latter, as I will at least get an exception screenshot showing the box before it is killed.

1 Like

If it is something you need and if this thing come-up occasionally, how about use of parallel processing to see if this pops up and close and open it again within the parallel process.?