Hi Thomas;

  Please upgrade to Maintenance Release (MR) number 2170 if you are not on that build. The MR downloadable is available from your User Center on the Appeon Website.

  Also, please check ...

1) Optimize all your PBL's after migration (before is also recommended).

2) Check your external API calls. If possible, make sure they are Unicode compliant. Especially, for W10. For eample, I can to convert to using FindWindowW from FindWindowA when I migrated by framework to be W10 compliant 5 years ago. The old ANSI flavour would not work at all in W10 but was fine in W7 or when run from PB 12.x.

3) Try running your IDE / Apps as ADMIN. If that works, there could be permissions issues.

Regards ... Chris

Hi, agree with René including follow-on tip from Miguel.
What happens when you run app via the PB Debugger?

Faster than /PBDEBUG >>> Add MessageBox at start and end of App.Close; then run app again. Whether none, one, or both messages appear tells you what type of issue your app has.

1. No messages => App hangs before App.Close
   Some window remains open (potentially hidden; resized to <0,0> or placed outside visible screen area)
   
   1. Breakpoint in debugger at end of main window's Close event can tell you "Objects in Memory"
      
      
2. One message => App hangs halfway through App.Close
   
   1. Now, adding/moving message boxes can identify exactly what statement is culprit.
      
      
3. Both messages => App hangs after App.Close
   After close-event the PB runtime destroys all remaining objects in memory.
   Somewhere somehow a resource remains open despite all PB objects destroyed.
   1. Could be Timing object with timer started without later stop.
      Could be file locked due to FileOpen without FileClose.
      Could be OLEObject being destroyed without prior DisconnectObject.
      Could be code in external DLL that won't release its memory
      Could be probably something else I forgot at the moment 
   2. Breakpoint in debugger at end of close-event can tell remaining "Objects in Memory"
      NOTE: Some "locks" don't show as objects, like DLL holding resources or missing DisconnectObject.

HTH /Michael

In addition to René´s valuable advice:

Running with /pbdebug takes a very long time to get to test the point where your application crashes, but ...

Roland Smith has invented this nice little way of being able to activate /pbdebug at runtime at any point of running your code: https://www.topwizprogramming.com/freecode_pbdebug.html

I haven't used it myself, but it seems pretty straight forward.

---------------------------------------------------------------------------

In the n_pbdebug object, local external function declarations, replace pbvm105.dll with pbvm190.dll:

Function long rt_dbg_on() &
Library "pbvm105.dll"

Function long rt_dbg_off() &
Library "pbvm105.dll"

Function long rt_dbg_set(long option) &
Library "pbvm105.dll"

Function long rt_dbg_del(long option) &
Library "pbvm105.dll"

Function long rt_dbg_outfile(string filename) &
Library "pbvm105.dll"

Hi Thomas,

I think it may be something wrong with your application. You should try to find out what statement is the last before the crash.

Run you exe with /pbdebug parameter (or from IDE with PBDebug Tracing enabled from "General" tab of the "System Options" dialog). It creates a debug file (a text file) that logs every line of code.

HTH, 

René