PFC Guide Titlebar
HomeFAQLinksPFCMAGExtensionsDownloadWhat's NewSearch

GPF FAQ


Table of Contents

I am getting a GPF running my application

Contributed by Sharon Buntz

Here are the top reasons why you would get a GPF while running your application.

  1. In the development environment, check your PowerBuilder Search Path - Are all eight PFC/PFE PBLs there (pfcapsrv.pbl, pfcdwsrv.pbl, pfcmain.pbl, pfcwnsrv.pbl, pfeapsrv.pbl, pfedwsrv.pbl, pfemain.pbl, pfewnsrv.pbl)? Are all other PBLs there, too? Also, make it a practice to go out of PB and back in whenever you change your PB Search Path. There were some bugs in 5.0.
  1. Running an EXE, check to make sure that all of your application's PBDs/DLLs are in your application's path. After a build, you must go round up all of the PBDs/DLLs. Each one can be found in the directory where its source PBL was located. Also make sure that the correct version of the PowerBuilder runtime DLLs is in your application's path.
  1. Are you running the same version of PowerBuilder as you are running the PFC version? For each 5.0.## release, you must run a full rebuild to regenerate all objects to the newer PowerBuilder version. Double check to make sure that you are running the same version of PowerBuilder and PFC source. (Check the about for PB, and check the instance varibles in pfc_n_cst_debug for PFC.)
  1. Try running a full rebuild. Running a full rebuild will properly regenerate all of your objects, in the proper hierarchical order. It should also handle regenerating objects which reference each other, such as regenerating the window and tab objects when a tabpage object changes.
  1. For 16-bit machines... Are you running low on GDI resources? Has your application been "Halt Close"ing lately? Have you gone out of windows and back in after every GPF? Memory management is poor in 16-bit operating systems. Try to avoid having your program "Halt Close". If you are running an MDI frame application, close the frame instead. But if you must perform a "Halt Close", at least first execute the destructor event on the Application Manager. This will ensure that the services will be destroyed.
  1. Is your PFC application not closing by itself? Some people discovered that that if you have a datastore that your application was using that has not yet been destroyed, your application will not close naturally. A common fault is calling the Error Service's of_LoadPredefinedMsg() and then not destroying the Error service before trying to close your application.
  1. Are you reading in any of your DataWindows in 'async' mode, meaning that you have any code in any of your DWs' RetrieveRow events? or does your transobject somehow have SQLCA.dbParm = "Async = 1" set? or have you specified dw_1.Modify("DataWindow.Retrieve.AsNeeded=Yes")? If so, and if you close your window "too fast" (before the retrieves complete without calling a DBCancel), your program will GPF.
  1. Are you somehow fragmenting memory unknowingly, by say perhaps calling a lot of 'autoinstaniated' NVOs? This can happen when say calling a lot of PFC n_cst_string functions like of_PadLeft(), all in one big string statement. The GPFs were flaky and hard to pinpoint to exactly what was actually causing it, since the GPFs seemed random.

For other GPF resolution tips see the Faxline docuents below:

44536 -
42089 -
47703 -

Contributed by PFCGuide staff, except where noted otherwise.
PFCGuide is sponsored by Dynamic Technology Group
The information provided is for advice only and not to be considered a contract or a liability against Dynamic Technology Group.

Last revised: February 15, 2004 03:58 AM.