Bug 7784

Application Locks Up Closing Window with Large Dataset 21 January, 2022

Christopher Craft
12 January, 2022
Product: PowerBuilder Category: DataWindow
Version: 2019 R3 Build: 2670
Classification: Publishing: Public
Priority: P2
Status: Verifying Reason:
Communication Status: Waiting for Customer
Chris Pollach @Appeon 21 January, 2022
#17
Hi Chris;

   That is a great point about the ShareData feature.

   In my STD framework, I keep an SD Boolean Switch variable and if this id ON in a DC or DS, then I bypass the Reset() on the Destructor.

   Also if you know that a SD is being used, then just override the ancestor code for the Destructor.

Regards .... Chris
Ken Guo @Appeon 21 January, 2022
#16
Hi Christopher,

About the 3rd point, our developer has confirmed that “Accessibility=0” only disables Accessibility for datawindow. Other controls are still using Accessibility so PB application will still load UIAutomationCore.dll.

Regards,
Ken
Christopher Craft 20 January, 2022
#15
(In reply to Chris Pollach @Appeon from comment #1)
Hi Chris;

  FWIW: I have circumvented this in my STD framework for decades by using
the following code on my DW Controls and DataStores.

  In the DC & DS "Destructor" event ...

THIS.Reset()           // Release All DWO buffers
THIS.dataobject = ""   // Release DWO itself

  This has always seemed to assist the PBVM runtime to release DWO resources
more prudently for me over the past few decades.

PS: Hopefully, you have an ancestor for all DC's & DS's where you can drop
in the above code.

HTH
Regards ... Chris
Chris - Just wanted to post an FYI about your clearing the DW/DS at Destructor. I just spent a couple hours tracking down a problem related to this and the use of ShareData(). You should add a ShareDataOff() before you Reset() and clear the DataObject otherwise you have just cleared the data of the primary shared DW which, in my case, I did not want to happen.
Ken Guo @Appeon 20 January, 2022
#14
Hi Christopher,

1. In fact, PB 2017 R3 also has a performance issue in this aspect, you can refer to Bug 544. We also started suggesting setting “Accessibility=0” to work around the issue from that time.
To implement the Accessibility feature, PB 2017 R3 and earlier PB versions used the MSAA method. PB 2019 R3 added the UIA method and thus make the issue easier to happen.

2. I don’t have a touchscreen PC to reproduce this issue but we did reproduce similar issues before and they were all caused by the call to the Accessibility feature and resolved by setting “Accessibility=0”.

3. Regarding the question that UIAutomationCore.dll is still loaded when "Accessibility=0", our developers are still further analyzing. I will tell you why later. I guess this "Accessibility=0" is only for datawindow, and other controls are still calling Accessibility, which requires developers to analyze and then confirm.


Regards,
Ken
Christopher Craft 19 January, 2022
#13
Few more clarifications:
1) Do you know why this was not an issue in PB 2017 R3?
2) When you tried to replicate my issue did you use a touchscreen PC to RDP into a 2016 server that had the TestApp.exe?
3) Why would PB call the underlying API to implement the Accessibility feature even when 'Accessibility=0' is in the PB.INI?

Chris
Ken Guo @Appeon 19 January, 2022
#12
Hi Christopher,

Yes. UIAutomationCore DLL is still loaded and it’s normal behavior.

I had downloaded your case but didn’t reproduce the issue.

For this DW performance issue, even with the same case, the issue is not always reproduced if in different environments.

PB calls the Windows underlying API to implement the Accessibility feature but it’s not clear why the performance varies among different environments and we still need to consult Microsoft for this.

Based on the case you provided, the issue phenomenon depiction and resolution, the issue you ran into is the same as the DW performance issue other customers of ours ran into previously. At present, we suggest you upgrade to the latest version and set Accessibility=0 to work it around.

Regards,
Ken
Christopher Craft 18 January, 2022
#11
I have run some tests with the latest runtime and the issue has seemed to go away BUT... the UIAutomationCore DLL is still loaded but it does not churn and consume a bunch of memory anymore. Is this the expected result?

I would like it if you could run a test on my TestApp that I provided to you to make sure that this issue is the SAME (not similar) to what the previous customer experienced as well as tell me what PB Bug was fixed in this latest release to address it.  For us to recompile and redeploy our application to address this issue I need to be assured that it was fixed. This is not a quick thing as I am sure you would understand if you had to do the same for PB.

Thank you,
Chris Craft
Ken Guo @Appeon 17 January, 2022
#10
Hi Chris Craft,

One of our customers ran into a similar issue before and they solved it by upgrading to PB 2019 R3 Build 2728 and then setting accessbility=0 in pb.ini. So I want to check with you:
1. Did you try upgrading to PB 2019 R3 Build 2728? Did you try setting pb.ini?
2. If you are using VPN, please try again after turning VPN off.

If the issue is not solved after you upgrade PB, I’d like to schedule a remote meeting with you. We are available for the meeting from Monday to Friday 9:00~17:00 UTC +8 Hong Kong time (which should be Sunday to Friday 8pm~4am EST). Please let us know when can you do the meeting and please let us know at least one day in advance so that we can set up the portal for the meeting.

Regards,
Ken
Christopher Craft 14 January, 2022
#9
FYI - I just got off the phone with one of our customers - they use a signature pad from some of the PC's in order to sign documents in our application so turning off the "Touch Keyboard and Handwriting Panel Service" is not going to be an option for them if it stops that from working.
Christopher Craft 14 January, 2022
#8
... And this was not an issue with PB 2017 R3 which is the release our customers are coming from.
Christopher Craft 14 January, 2022
#7
Ken,

I have already done all those things (as my original post stated).  Compiling in 64-bit is not an option as this is our deployed application to all of our customers.  

The test case I attached earlier will be able to replicate the issue.

Chris
Ken Guo @Appeon 14 January, 2022
#6
Hi Chris Craft,

I suggest you check if you set ACCESSIBILITY=0 as follows, if not, please follow the instructions below to try again:
1. First upgrade PB 2019 R3 2670 to PB 2019 R3 2728.
2. Then open the PB IDE pb.ini file (C:\Users\%username%\AppData\Local\Appeon\PowerBuilder 19.0\pb.ini). Add ACCESSIBILITY=0 under the Data Window node and then try again:
[Data Window]
ACCESSIBILITY=0 

3. If you compile your application to an EXE to run, then you need to add a pb.ini file to the directory where yourPBapp.exe resides, and this file contains the following content.
[Data Window]
ACCESSIBILITY=0

4. If the issue remains, please deploy the application as 64-bit then check if the issue still exists.

If the above cannot solve the issue for you, could you provide a small case that can reproduce this issue for our analysis?


Regards,
Ken
Chris Pollach @Appeon 13 January, 2022
#5
Well ... that is weird! 
Hopefully, Engineering will have some more input for you.
Christopher Craft 13 January, 2022
#4
Just had another customer call with the same issue - they are running the client on a Win 10 Enterprise for Virtual Desktop. The interesting part here is the PC running this does not have a touchscreen.
Chris Pollach @Appeon 13 January, 2022
#3
Hi Chris;

   Thank you for trying my suggested code change to the DC & DS object classes for large data retrievals!

   I know that in the Sybase versions of PB in the past that there were performance issues when PC's had "touch & hand writing services" active. However, I also thought that Sybase had addressed these issues by the time they got to PB v12.6 (which is the code base that SAP turned over to Appeon in 2016).

  I will now transfer this ticket over to the main Support / Engineering team to review this problem and test case (thank you for that BTW). Hopefully, they will have further feedback on this problem for you.

Regards .... Chris
Christopher Craft 13 January, 2022
#2
TestApp.zip (3965KB)

Adding those calls will help somewhat but does not circumvent the problem.

I don't know if this is the main cause but if tiptsf.dll (Touch services and Handwriting Panel Text Services Framework) is not loaded then the problem does not occur.

I have attached a test application.  Execute the TesApp.exe from a touchscreen PC and run the first Issue: 7784 - Large Dataset Causing Hang with Touchscreen.  This will open a large report.  Hit Close and it will take you back to the Issue List but it will now be locked up.  If you look at the CPU you will see it pegged. If you run Process Monitor you will see the UIAutomationCore.dll being accessed over and over again.

Chris Craft
Chris Pollach @Appeon 12 January, 2022
#1
Hi Chris;

  FWIW: I have circumvented this in my STD framework for decades by using the following code on my DW Controls and DataStores.

  In the DC & DS "Destructor" event ...

THIS.Reset()           // Release All DWO buffers
THIS.dataobject = ""   // Release DWO itself

  This has always seemed to assist the PBVM runtime to release DWO resources more prudently for me over the past few decades.

PS: Hopefully, you have an ancestor for all DC's & DS's where you can drop in the above code.

HTH
Regards ... Chris
Christopher Craft 12 January, 2022
Customers are reporting that after closing a large report (+/- 150 Megs) the application locks up. What I have found is these users are running a Win 10 PC with touchscreen against a 2016 Server. When the report closes the application will just start hitting the UIAutomationCore.dll thousands of times. I also have Accessibility=0 set in the PB.ini file but removing it does not change the result.

I have replicated the issue in house with a test server as well. This is a pretty high importance issue since most of our large customers use terminal servers and are running their year-end reports as well as doing tax filing.
OS:
Windows 10
Platform:
Database Type:
Database Version: