1. Lucia Radita
  2. PowerBuilder
  3. Tuesday, 8 October 2019 15:40 PM UTC

We are using Power Builder 2017R3 build 1858 for our POS application. The application runs on Windows Server 2016. We have a constant crash in a specific feature.

.Net Framework  3.5 (version 3.5.30729.4926 ) and 4.7 ( version 4.7.02558; release 461310)

In this feature a datawindow is dynamically modified having also a split column

The crash occurs before displaying the data

In Event Viewer the log data is:

//******************

Faulting application name: posisent.exe, version: 1.0.0.1, time stamp: 0x5b6318c2 => this is the name of our app.
Faulting module name: pbdwe170.dll, version: 17.2.0.1858, time stamp: 0x5b6319c8
Exception code: 0xc0000005
Fault offset: 0x00158bc3
Faulting process id: 0x%9
Faulting application start time: 0x%10
Faulting application path: %11
Faulting module path: %12
Report Id: %13
Faulting package full name: %14
Faulting package-relative application ID: %15

//****************** related .Net Runtime error

Application: posisent.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: exception code c0000005, exception address 722D8BC3

//*****************

Would you have any suggestions how to address this issue?

thank you

Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 8 October 2019 15:47 PM UTC
  2. PowerBuilder
  3. # 1

Hi Lucia;

  If this happens consistently, I would recommend using the PB IDE's "Debugger" on the PowerScript code that is modifying the DWO's properties & behaviour. By "stepping through" your related code you should be able to locate the problematic statement.

HTH

Regards ... Chris

Comment
There are no comments made yet.
Lucia Radita Accepted Answer Pending Moderation
  1. Thursday, 10 October 2019 20:43 PM UTC
  2. PowerBuilder
  3. # 2

The problem is not as simple as it looks. Running from Debug does not give any error. In the previous version of PB (10.2) there was no problem and the feature was not changed. We just migrated the code to PB 20017R3

The window is a response type and displays data in a datawindow (DB is SQL). The datastore is changed dynamically, the select and its properties. This response window is called from different modules and the datastore is slightly different, same for the SQL syntax. If just launching the application, call the window from module A => the exe stops working  (see pic)

The other scenario: launch the application and call the same window from module B(ex)=> data is displayed, no error. Then call the the window from module A => this time is not crashing anymore.We can call it n time and will not crash. But if exit the app and return to module A calling the Window => same crash

My guess is that first time the SQL is taking some time to build the plan and data retrieval is a bit longer; after same SQL plan is used and response is fast.

After migrating to new PB version we had to add some SetRedraw (false) to improve display time although some comments are stating that is not a good practice.

 

Comment
There are no comments made yet.
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Thursday, 10 October 2019 21:46 PM UTC
  2. PowerBuilder
  3. # 3

Hi Lucia, for this issue I recommend opening a support ticket.  But without reproducible test case Appeon support can’t help.

Comment
There are no comments made yet.
Mohammud Daulgha Accepted Answer Pending Moderation
  1. Sunday, 15 December 2019 23:51 PM UTC
  2. PowerBuilder
  3. # 4

We are experiencing the same issue in one of the production environment. As the issue does not happen in any of our development machines. Can someone share an ideas or steps to find the root cause of the issue will help to resolve the issue.

Comment
  1. Olan Knight
  2. Tuesday, 18 August 2020 23:18 PM UTC
Add a global boolean gb_debug = FALSE.

This boolean gets set either by a setting in the Windows Registry or by a PREFERENCES table.



Add messagboxes throughout the code like where appropriate, and displaying relevant data.

IF (gb_debug) THEN

MessageBox ('Error in function XYZ", "Something bad occurred" + "~r~n" +sqlca.sqlErrText)

END IF



When attempting to determine the cause of the error, set the value of the Registry entry for DEBUG to TRUE, and run the code.



Olan



  1. Helpful
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Monday, 16 December 2019 00:59 AM UTC
  2. PowerBuilder
  3. # 5

Why would SetRedraw(false) be bad practice? We use it everywhere all the time. You just have to be careful to set it back to true before any popups like messageboxes and / or other windows opening.

 Is your executable "machine code" or interpreted (PBD?). Try PBD if not. Is the datastore present in a PBR file if not PBD used?

This might sound funny but "one thing you could try" is to make sure the exported datastore starts with "release 17;". Migration does not change the version. Best thing to do would be to edit the dw (not the source) and then just move anything a pixel to the right and then back to the left (or something similar), just to be able to "save" the datastore. This way you ensure all new attributes are present in the new format. (might not help but surely won't harm).

Also make sure there's a default printer on the PC assigned in windows.

Another thing: Does your module A maybe have another datastore with a long similar name? We have had sometimes problems of powerbuilder "confusing" one with another if that was the case. Make sure there's some difference somewhere in the let's say first 18 characters in the naming if this is applies to your module A. (I don't remember the exact amount of characters when that possible problem might occur).

Nothing else I can come up with at this moment.

Good luck.

 

Comment
  1. Olan Knight
  2. Tuesday, 18 August 2020 23:15 PM UTC
At one time there was a rule that any PB object name had to be 30 characters or less, not counting the extension.

If you stick to this rule you'll never have issues with object mistaken identity.



Olan
  1. Helpful
There are no comments made yet.
Ken Guo @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 17 December 2019 07:44 AM UTC
  2. PowerBuilder
  3. # 6

Hi Lucia,

 

Due to that we can’t reproduce this issue locally, it is hard for us to find out the root cause of it for now.

Can you provide a small reproducible case for us? If yes, please go to Appeon Support Ticket system(https://www.appeon.com/standardsupport/newbug) to open a new ticket with this small case thus it can be properly received and tracked.

 

Regards,

Ken

 

Comment
  1. Lucia Radita
  2. Wednesday, 18 December 2019 14:51 PM UTC
Hi Ken,

We will try to build a small app to see if we encounter the same problem. I think the "context" of the application (ours is not a small one) has an impact in regard to this problem. Generally, since we migrated the application to PB 2017R3 / OS Windows Server 2016, we observed that the UI refresh is longer and we had to add SetRedraw(false) in several modules to improve display time.



Regards,

Lucia
  1. Helpful
  1. Ken Guo @Appeon
  2. Thursday, 19 December 2019 02:31 AM UTC
Hi Lucia,



I am very grateful that you are trying to build a small application for us. This will really help us a lot in analyzing and handling this issue!

Once you build this small app, please go to Appeon Support ticket system (https://www.appeon.com/standardsupport/newbug) to submit a bug and upload this small app.

Thanks in advance.



Regards,

Ken

  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 18 December 2019 19:03 PM UTC
  2. PowerBuilder
  3. # 7

Hi Lucia;

    Just an FYI that PB 2017 R3 MR02 was released today (build 1915). If you can, you might want to try this latest LTS build of PB 2017 and see if that helps your situation.

FYI: https://www.appeon.com/company/news/powerbuilder-2017-r3-and-infomaker-2017-r3-mr-1915-released.html

Regards ... Chris

Comment
  1. Lucia Radita
  2. Monday, 17 August 2020 21:54 PM UTC
Hello Chris,

Thank you for the suggestion. We delivered the application using original PB 2017R3 build #1858. We tried to mitigate the problem from the code although the dws are dynamically built, many property changes, use of dw split. Unfortunately, the client is facing randomly the crash I initially mentioned. Changing the PB build version is not an easy decision.

My question is: if we download the new PB 2017R3 build #1915, build/ test our application but we face same issue or something new can we return back to PB 2017R3 build #1858?

Thank you,

Lucia
  1. Helpful
  1. Chris Pollach @Appeon
  2. Tuesday, 18 August 2020 00:29 AM UTC
Hi Lucia .. yes you can. I'll do another formal reply to this post on how to do this.
  1. Helpful
  1. Olan Knight
  2. Tuesday, 18 August 2020 23:13 PM UTC
Before doing anything, make a copy of your PB 2017R3 b1858.

THEN and only then download and install the new build. Copy the code into the appropriate b1915 folder, do a FULL BUILD, and try again.



If you decide not to stay with b1915, the entire 1858 folder is still there. Simply do a Full Build in 1858 when all is said and done.



Good Luck,

Olan
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 18 August 2020 00:40 AM UTC
  2. PowerBuilder
  3. # 8

Hi Lucia;

   Here is how I run multiple builds of any PB version. I have been using this technique successfully for over 2 decades, as follows:

My current actual setup for PB 2017 R2 & R3 switching (build 1880 & 1915)

  1. Copy the current "PowerBuilder 17.0" folder to "PowerBuilder 17.0 - Bnnnn" (my personal convention)
  2. Copy the current "Shared" folder to "Shared - Bnnnn"
  3. Install the next version / build of PB 2017Rx
  4. Copy the updated "PowerBuilder 17.0" folder to "PowerBuilder 17.0 - Bnnnn" (backup)
  5. Copy the updated "Shared" folder to "Shared - Bnnnn"

Now to activate any version / build - copy the Bnnnn folders back to their primary names. To switch back - delete the primary folder names and copy the other Bnnnn folders back to their primary names.

Tip: For faster switching, just rename the Bnnnn folders back to their primary names. If you forget what version/build your on, just start the IDE and check the version/build in the IDE's bottom rh-bottom corner when it starts.

HTH

Regards ... Chris

PS: Same approach for PB2019Rx as well.

 

Comment
There are no comments made yet.
Jeff Hersey Accepted Answer Pending Moderation
  1. Tuesday, 18 August 2020 17:13 PM UTC
  2. PowerBuilder
  3. # 9

was there any resolve to this?  We have experience similar issues - our program is just 'vanishing', and windows is reporting it is the pbdwe19.dll or the comctl.dll.

 

Jeff/

Comment
  1. Chris Pollach @Appeon
  2. Tuesday, 18 August 2020 17:55 PM UTC
Hi Jeff;

The comctl32.dll is a module that contains common GUI components used by Windows applications.

What MS-Windows version & build are you using?

Regards ... Chris
  1. Helpful
  1. Jeff Hersey
  2. Tuesday, 18 August 2020 18:05 PM UTC
From the windows crash log file ... here are the dll's loaded when it happens. We are running a win32 app





LoadedModule[40]=C:\WINDOWS\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.9659_none_d08cfd96442b25cc\MSVCR80.dll

LoadedModule[41]=C:\WINDOWS\SYSTEM32\VERSION.dll

LoadedModule[42]=C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.18362.959_none_2e74f29627888bc1\COMCTL32.dll

LoadedModule[43]=C:\WINDOWS\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.18362.959_none_5f5fe57b821b058f\gdiplus.dll
  1. Helpful
  1. Jeff Hersey
  2. Tuesday, 18 August 2020 18:07 PM UTC
- Windows 10 is up to date



  1. Helpful
There are no comments made yet.
Daryl Foster Accepted Answer Pending Moderation
  1. Wednesday, 19 August 2020 04:36 AM UTC
  2. PowerBuilder
  3. # 10

Hi Jeff, I had pretty much the exact same error as the original poster, so it didn't involve comctl.dll like yours.  But in my case it was an application to create and send emails.  It would work for around 160 of them, and after that it would crash out with the pbdwe170.dll Exception code: 0xc0000005 error.

It turned out my issue was with a datastore that I was dynamically creating in an object function but not destroying.  After I added the destroy line in it seems to work fine.  From that I'd assumed my error was either memory or garbage collection related.

Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.