A couple of months ago, we started getting complaints from users of PI Processbook closing when using certain displays. Symptoms were that they would have the processbook display open, then with no error message, no nothing, Processbook would close.
The issue affects different users on different machines, but on the same file(s). Given that nothing changed on the file side or the application side, I assume it is a change in the OS - probably a security patch or similar (Win10, 64bit). The Windows Dump file said it was trying to write to memory that it didn't have access to, and the faulting module was KERNELBASE.DLL
The affected displays have VBA code (and as such, OsiSoft technical support can't "support" resolution of the issue, and hence they recommended that I post it here).
I have tried to diagnose the issue, but to no avail. Summary of findings:
- Updating to the latest release of processbook and associated libraries has no effect.
- It does not affect all displays that have VBA code, the ones that appear to be affected are those that have calls to databases (Oracle and MS Access)
- VBA Code does not have to be running for the crash to occur (in fact, it appears to happen when there is NO code running).
- Displays typically have a few DLLs referenced: (in addition to normal "PI" ones)
- Microsoft Forms 2.0 Object Library
- Microsoft ActiveX Data Objects 2.8 Library
- Microsoft Scripting Runtime
- Microsoft XML, v6.0
- Microsoft WinHTTP services, version 5.1
- I've fully check all the code that runs, and I don't see anything too problematic. There were a few recordsets not getting explicitly closed (although the VBA garbage collection / reference counting should clean them up when the go out of scope), but I changed it to explicitly close them. It made no difference.
Any suggestions? I can't pin it down to a specific Windows Update...