The 32-bit version of the app works fine and when we first migrated and created the 64-bit version of the app using PB 2019 the app loaded and exited and everything in between ran with no issues. Since then we've upgraded to 2019 R3 Build 2728 and now when I exit I get an error message that the application has stopped working and please close the program. It also gives me the option to debug the program. In doing so I get the attached screenshots. I should mention, we use a dedicated server to build our exes and it is still running the original PB 2019. We also user PowerGen version 11 to create our exes. We do NOT have any databases connected to the application. Everything is stored externally and is retrieved through COBOL via a 64-bit DLL. Our system administrator is adamant that I should be able to debug through the code. I've tried explaining that the IDE is 32-bit and can't be debugged in 64-bit mode and gave her the .dbg trace file that shows everything, including the environment, has been destroyed.
We did migrate from PB 7 to PB 2019 which is a huge migration but there were zero errors. The migration added the "Alias for" to the dll calls. But, since there is such a learning curve, am I missing something with the debug option? Can I actually break into IDE debug mode in the middle of running the application like she's suggesting? Personally, seeing that the IDE is 32-bit and the application is 64-bit I don't see how but I could be completely misunderstanding that part of it.
Oh, two other things. I did recreate the exe using PB 2019 R3 and used the runtimes from the runtime packager and got basically the same result but pbshr.dll instead of pbshr190.dll and I'd be more than happy to include the .dbg trace file if anyone wants to page through 834,811 lines of code (which is just the open and close of the app). I would strip away the meaningless parsing and whatnot of course. Anyway, any help would be greatly appreciated because I am at a complete loss!! We have some clients that are wanting to merge over to a 100% 64-bit application and this is now the hold up.
Aimee
1. I am not certain whatsoever. Our system admin is the one who is adamant that there's a memory leak from the PB application. Here's the end of the .dbg trace file:
End class function +DESTROY for class PFW_N_CST_APPMANAGER, lib entry PFW_N_CST_APPMANAGER
End class function +DESTROY for class N_CST_APPMANAGER, lib entry N_CST_APPMANAGER
End class function +DESTROY for class N_CST_FUNDS_APPMANAGER, lib entry N_CST_FUNDS_APPMANAGER
Executing object function +DESTROY for class ENVIRONMENT, lib entry _TYPEDEF
End object function +DESTROY for class ENVIRONMENT, lib entry _TYPEDEF
It appears to me that everything that I've requested to be destroyed has been destroyed. She says something about closing the DLLs but I never open any DLLs so how am I supposed to close them? Our application was built using the PFC framework back in 2000 and we had someone from Sybase come in and help us create our framework. The open and close code hasn't really changed much since. Create the application manager, security object, etc then destroy them upon close.
Regarding COBOL DLLs, after I recreated the exe using PB 2019 R3 and performing the debug I got this:
'fundgui.exe': Loaded 'C:\netexpress51\Base\Bin\Win64\cob32api.dll', Cannot find or open the PDB file
The thread 'Win64 Thread' (0x2a98) has exited with code 0 (0x0).
Unhandled exception at 0x655e7cb6 in fundgui.exe: 0xC00000005: Access violation reading location 0x00007fffff309d008.
2. I do not believe I went through any 64-bit migration steps - didn't know I needed to - but I possibly could have seeing it's been a year ago. I'll look into that first thing in the morning. However, what confuses me the most is that when I first performed the migration and created the 64-bit exe it worked fine. And now just simply performing the open and immediately exiting we get the error. Of course, it is a different PB release/build and I don't know if that affected anything.
Thank you again!
Have you tried running the PB app using "Run as Administrator" option?
Are you using latest PFC libraries? Changes were made to support 64-bit. https://github.com/OpenSourcePFCLibraries/2019
I don't know exactly what's causing it, but these are some possible things to consider.