If you're looking for a memory leak where you're not destroying created objects, one of the things you can do is look at GDI objects on the Windows machine. See attached image of the task manager.

In Task Manager (Details tab on Windows 10), add GDI Objects to the viewed columns. If this number keeps growing the longer the application is open, then things are not being destroyed properly. 

A couple years back on a Windows 7 machine (don't remember if it was 32 or 64 bits), once that number got to around 10,000, the application would GPF. I haven't played with this recently, so I don't know what the new OS thresholds are.

Generally, you should see the number grow when opening windows, and upon closing, you should see the number shrink.

Hi Olan;

  FWIW: The xxxxxxxA API's should become xxxxxW as PB is now fully Unicode. Its probably not the source of your stability issue, but I have found that some "A" API's will no longer work properly under newer O/S versions like W10 and/or W2016/2019. The same when you run the App EXE "as Admin" mode. You have to careful of that mode as W10 imposes run-time restrictions on certain API's.

  Your current problem (and even Julian's) though could be due to "orphaned" NVUO's that never get destroyed (even by garbage collection) and eventually over time (aka Long Running Apps), get to the point where the App's current address space runs out of usable memory.

  I am now just addressing this issue in my frameworks as they now track all NVUO's (standard and custom). The idea was to provide a guide to the PB developer at debug time or when running the App in "debug mode" of all the NVUO "creates" that were performed, what NVUO's are in memory at a debug break point and also importantly, what NVUO's are hanging around and never get destroyed until at Application close. Hence a road-map to make sure that your PowerScript code is always cleaning up after itself (in other words - don't trust garbage collection).

  Here is an example test case. My framework uses a DataStore to track what Menu Items the user navigates through as a statistic gathering feature. The menu item stats are recorded in a DataStore and then logged on destruction. The menu's DSs get destroyed when the menu is destroyed (OK, menu's do not have constructors or destructors events but, my framework adds support for these - "kool" or what). Now if I remove the clean-up code from my ancestor menu's destructor, as follows:

    io_ds_stats.Reset ( )
    io_ds_stats.DataObject    =    ""
    // Destroy io_ds_stats

  Since the framework now tracks all NVUO's, here is what the framework's Debug Trace looks like after opening a few Windows and then closing them...

 Even minimizing the App's MDI frame & restoring or calling Garbage collection method - the orphaned NVUO's are still instantiated and keep growing. They are never cleaned up by the PB run-time (probably a bug but, none the less an issue). So if this is a long running app, one that CREATE's DS's or other NVUO types using a local variable - especially in a big Loop OMG), then 100's if not 1,000's of these orphaned NVO's will grow over time. Once they grow to the point where the PB App has no more "safe" memory within its address space ... WHAM-O - your app instantly crashes and most likely, with no error message from the PBVM and/or Mr Bill (aka Windows O/S).

Food for thought.

Regards ... Chris

 PS: This NVUO tracking code also works in PowerServer Web and Mobile Apps!

Maybe the profile is getting too large due to having many files stored in it.

Julian -
   Sadly, we have not yet determine the cause of this issue. It's difficult to track because it occurs so infrequently and we have no idea on how to force the error.

   You know the saying, "if we can duplicate it we can fix it, but if we cannot duplicate the error then...".


Olan

Hi Olan,

I think we could have a similar problem. Did you find the solution?

Our application crashes randomly on some client PCs. When this happens, 
if the user reboots the PC or we access in the same PC with another user 
and do the same operation in the application, it works.

It seems that this happens more often to users who keep the windows session open several days.

Regards,
Julián