1. Vlad V.
  2. PowerBuilder
  3. Monday, 19 November 2018 11:53 AM UTC

Hi, our client have an annoying problem with our PB application that started happening ever since they upgraded their PCs to Dell laptops, Windows 10 Pro (used to run on Windows 7 before that). Our application is compiled in PB 2017 (Universal) R3 1858.

Apparently, the problem manifests when they click away to another program or window, and then click back to our PB application icon on the taskbar to make it again the active application, when they get either/or

"FATAL DISK ERROR"

or, more worryingly, a "silent crash", faulting in ntdll.dll module, I will paste the event log trace below. If I understand correctly, and I'm still gathering precise information, the procedure seems to be:

1. users working with PB app
2. users make another window, Chrome or Outlook, or whatever, the active application
3. clicking back on the taskbar to switch back to our PB app makes it crash


Here is the thing - I do not believe it is a problem with Powerbuilder as such, and not with R3 either. Prior to this, they had a version of the same application compiled in PB 11.5.1, build 4011 (back from 2009) producing the identical behaviour, and we only upgraded to R3 compiled version thinking that the problem is in Windows 10 compatibility with very old PB. But it's not - same behaviour persists.

We have several clients using Windows 10 PCs reporting nothing similar at all - it is probably something to do with the series of these Dell laptops or a particular way that they are configured, or additional software that came with it - either some manufacturer Dell settings, or the AntiVirus perhaps.

All laptops are:
Inspiron 13 5000 Series (Windows 10 Pro)
AntiVirus: Bitdefender (we already attempted to remove it / disable it, crashes still occur)

But I wondered in the meantime if anyone can recognise this behaviour or if someone has the first clue what to attempt.

Unfortunately, we (still) do not have one of the laptops in question to do our own testing.

 


Here is the event log:

Log Name: Application
Source: Application Error
Date: 13/11/2018 13:12:18
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: 46809L.network.local
Description:
Faulting application name: codex.exe, version: 1.8.0.9, time stamp: 0x5b6318c2
Faulting module name: ntdll.dll, version: 10.0.17134.254, time stamp: 0xbf2f8c99
Exception code: 0xc0000006
Fault offset: 0x00062c3d
Faulting process id: 0x9c0
Faulting application start time: 0x01d47b3c53038bee
Faulting application path: P:\LocalTrade\codex.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: c31b17f6-773e-4964-90ec-bd4736d322c6
Faulting package full name:
Faulting package-relative application ID:

 

 

Brad Mettee Accepted Answer Pending Moderation
  1. Monday, 19 November 2018 14:37 PM UTC
  2. PowerBuilder
  3. # 1

Even if you can't repro locally yet, this might help.

The "Fatal Disk Error" from PB typically occurs when the machine has been in sleep mode and, after waking up, PB can't re-use the file handle(s) it had open for it's own use. PB opens it's own application exe/pbds to directly read resources (images/datawindows/etc.) and maintains open handle(s) while running. This same error can occur when a network resource gets closed while PB is actively running from it. (your app appears to be running on network drive P: )

Does this occur if they login to your application, then immediately switch out to something else and come back? Or do they need to do something else in your app first?

Does the problem seem to be time related? (if they're out of the codex.exe for prolonged period of time)

Do you have code in a getfocus/losefocus event (main window or any subsequent windows)?

Does the crash occur when they switch out (where they wouldn't see it immediately), or when they switch back? After they switch out of your app, have them mouse over the task bar to see if an error window has shown up before they switch back into your app. That will at least tell you if it's on leaving your app, or re-entering it that causes the crash.

You might also have them try to run the app from a cmd prompt with /pbdebug on the command line. The resulting .dbg file ('appname'.dbg) should have a trace of your app right up to the crash point (depending on how it crashes, it *might* not be exactly on the line that caused the crash). They can zip & mail you the debug file, it should compress to be pretty small.

Hope this helps,

Brad

Comment
  1. Marina Grafit
  2. Thursday, 14 November 2019 13:51 PM UTC
Hi Vlad,



Have you resolved the issue ?



Thanks
  1. Helpful
There are no comments made yet.
Vlad V. Accepted Answer Pending Moderation
  1. Monday, 19 November 2018 14:59 PM UTC
  2. PowerBuilder
  3. # 2

Hi Brad, thanks for the reply.

Apparently, the problem is highly intermittent, and sometimes it happens after 20-30 minutes, and sometimes happens once or twice a day after hours of system use. From what I have gathered so far, the problem is not so direct as to happen every time they switch to another program and then switch back. I am visiting them tomorrow so I will try very hard to come up with a solid re-create routine on their own hardware.

I also remember why "Fatal Disk Error" happens usually - what is bizarre is that as one of the first steps we tried is that we copied the application to run straight from the local hard drive, so that the only connection to the server is an ODBC database traffic.

Yes, a lot of our windows have getfocus/losefocus, but primarily, in fact, I'm sure ONLY on datawindows - to AcceptText() during losefocus, and nothing more. Certainly nothing that you would expect to cause a crash.

Right now I have no information about some of your other questions, like does it crash immediately after switching out, when I try to recreate it tomorrow I will try to mouse-hover over taskbar to ascertain the status.

Really, I somehow feel that "FATAL DISK ERROR" is less relevant, it's really the silent crash that event log notes as a fault in ntldll.com that is really worrying me.

But I agree there is right now a lot of unknowns in here. By tomorrow afternoon I will hopefully have a lot more information, I guess this was a preliminary question just to see is there some "basic" instability of PB 2017 on Windows 10 that I was not aware about. I am highly sceptical though, as the same instability was present on PB 11.5-built application just as on the latest R3 one.


Cheers for that /pbdebug switch hint. I wasn't aware of it, and it could just prove very useful.

Thanks

 

Comment
  1. David Peace (Powersoft)
  2. Monday, 19 November 2018 17:01 PM UTC
I wouldn't be too fast to dismiss the fatal disk error as this may be pointing to a corrupt dll somewhere.



You might want to take a look at this article about using DISM.exe to validate and fix the windows dlls https://support.microsoft.com/en-us/help/929833/use-the-system-file-checker-tool-to-repair-missing-or-corrupted-system



Although I would first want to get a better handle on when exactly triggers the crash. Once you have seen it for yourself, let us know and we will do our est to help.



Cheers

David
  1. Helpful
  1. Vlad V.
  2. Monday, 19 November 2018 17:45 PM UTC
Thanks David,



That's on the long to-do list for sure, just... difficult to believe that all laptops of that series only have a win 10 corrupt DLL.



But then again, I've seen stranger in my time.
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Monday, 19 November 2018 17:22 PM UTC
  2. PowerBuilder
  3. # 3

Hi Vlad;

   I wonder if its some PowerScript code on a Get/LoseFocus or Activate/Deactivate event that is causing our grief? This problem could also be manifested by Timers or the use of User Events, mapped to MS-Windows low-level event messages that get fired in moving away and then back to, your PB App.

Food for thought.

Regards ... Chris

Comment
  1. Vlad V.
  2. Monday, 19 November 2018 17:44 PM UTC
Hi Chris,



I'll know more tomorrow, but AFAIK today, I am almost 100% this is not so. Surely that would crash the application on any environment (or at least, any Win 10 environment?). The source code between the 11.5.1 and PB 2017 R3 version is identical, and all of them experience the same behaviour on this particular series of Dell Win 10 laptops, whereas on other Win 10 machines, everything seems just fine?



In any case, you probably haven't seen it, but I've put a brief explanation above, nearly all we've got on LoseFocus are AcceptText() calls, nothing that exciting.
  1. Helpful
  1. Chris Pollach @Appeon
  2. Monday, 19 November 2018 17:56 PM UTC
Is this a PFC based App?
  1. Helpful
  1. Vlad V.
  2. Wednesday, 21 November 2018 16:27 PM UTC
Yes, PFC based.
  1. Helpful
There are no comments made yet.
Vlad V. Accepted Answer Pending Moderation
  1. Wednesday, 21 November 2018 14:48 PM UTC
  2. PowerBuilder
  3. # 4

Well, I had a look at client's laptop yesterday - I was poking about with it for nearly two hours, opening random windows, reports, saving to PDF, saving to Excel, however I could not make it crash. Luckily, another person was there with me, working on the system, and her laptop experienced one crash of our application, and it was, surprisingly, different that what I've been told few days ago.


So everything from my original post how this mostly happens when clicking back on the application which is not presently active on the task bar to bring it back as active application should be ignored. The problem is completely intermittent, it will sometimes happen once a day, and sometimes it will happen 10-15 times a day.

However, it can happen at absolutely any time, our application active or just made active back again, on the windows retrieval or not, and yesterday it happened quite literally when clicking on one menu of the main menu bar without any other windows within the application open

The application screen simply disappears. There is no error message of any kind, not even a generic "X.exe has stopped working...", the crash is completely silent, and the application just goes away. Event log trace does state an error in ntdll.dll file as stated above, but apart from that - nothing. 


I tried including the /pbdebug option when I started the application once, but it proved unreasonably slow. I'm not sure I can ask clients to run that in runtime environment when they're working in the system, as it takes over 60 seconds to open one screen. And only after opening 2-3 windows, the debug file was almost 40 megabytes large. Seeing that the problem can only manifest itself perhaps once in a day, I'd hate to think how large the debug file may be after 5-6 hours of system use. And I think our client would simply find system usage at that terribly speed unbearable.


Comment
  1. Vlad V.
  2. Wednesday, 21 November 2018 16:31 PM UTC
Hi Chris,



Thanks for words of wisdom. I see what you're saying, it's just... I have personally put in only one External function which is not even in use, that section of code is 100% disabled by a parameter. There's plenty of others in PFC source code that I can't really confirm if they are really used, or in some other functionality, for example, when exporting datawindows to Excel.



But the thing is... Surely this would all cause it to crash on a certain action? And according to data I had, the users have noticed this happenning when (1) clicking back to application, (2) typing the data into one datawindow field, or as I witnessed last night (3) just a click on the menu bar which should simply collapse the menu. And this was happening for the identical source code compiled on 11.5.1 and PB2017 R3.



So, seeing that I never had a problem on my Win 10 laptop, and on our other Win10 clients... is it really wrong to suspect that there is something not quite right with that particular series of laptops?

  1. Helpful
  1. Chris Pollach @Appeon
  2. Wednesday, 21 November 2018 17:38 PM UTC


Yes, it certainly seems that something (hardware or software) unique to a few PC's is aggravating the situation.



FWIW: I am always suspicious though of PFC's though when the PB App user has not migrated to a PFC version that matches the respective PB version. This has caused me no grief in the past with helping other PB developers with random crashes.



An interesting support ticket this AM on a Filter() method crashing the PB2017R3 App only on certain PC's. Turned out that this only happens when the App User sets their default printer to "Microsoft Print To PDF". Any other printer set to the default and this GPF does not happen. Weird or what?



So it might be something subtle like a default printer, anti-virus setting, 3rd party software (ie: TeamViewer) only on some PC's, hardware issue like a video card driver, touch screen feature, etc.



Food for thought.
  1. Helpful
  1. Vlad V.
  2. Wednesday, 21 November 2018 18:50 PM UTC
Interesting thought. When I migrated to PB2017 first I tried running it all on PFC11 first, it actually worked flawlessly, but in the end I did migrate to latest PFC17, with no issues.



But yes, some good indicators. I remember some Teamviewer setting that changed default windows title bar, and this somehow caused PB to crash during development phase, when working on datawindows with retrieval arguments. Astonishing.



Also, Touschscreen service used to crash PB 11 apps on Windows 8 and 10, confirmed.



As for this, I'll keep looking. Perhaps this thread will be useful to somebody in the future.
  1. Helpful
There are no comments made yet.
Brenton Scott Accepted Answer Pending Moderation
  1. Tuesday, 16 July 2019 03:44 AM UTC
  2. PowerBuilder
  3. # 5

Hi Vlad,

Was there ever a solution to this issue.

We have exactly the same issue with a client when they migrated to Windows 10.

Regards,

Brenton Scott

 

 

 

Hi, our client have an annoying problem with our PB application that started happening ever since they upgraded their PCs to Dell laptops, Windows 10 Pro (used to run on Windows 7 before that). Our application is compiled in PB 2017 (Universal) R3 1858.

Apparently, the problem manifests when they click away to another program or window, and then click back to our PB application icon on the taskbar to make it again the active application, when they get either/or

"FATAL DISK ERROR"

or, more worryingly, a "silent crash", faulting in ntdll.dll module, I will paste the event log trace below. If I understand correctly, and I'm still gathering precise information, the procedure seems to be:

1. users working with PB app
2. users make another window, Chrome or Outlook, or whatever, the active application
3. clicking back on the taskbar to switch back to our PB app makes it crash


Here is the thing - I do not believe it is a problem with Powerbuilder as such, and not with R3 either. Prior to this, they had a version of the same application compiled in PB 11.5.1, build 4011 (back from 2009) producing the identical behaviour, and we only upgraded to R3 compiled version thinking that the problem is in Windows 10 compatibility with very old PB. But it's not - same behaviour persists.

We have several clients using Windows 10 PCs reporting nothing similar at all - it is probably something to do with the series of these Dell laptops or a particular way that they are configured, or additional software that came with it - either some manufacturer Dell settings, or the AntiVirus perhaps.

All laptops are:
Inspiron 13 5000 Series (Windows 10 Pro)
AntiVirus: Bitdefender (we already attempted to remove it / disable it, crashes still occur)

But I wondered in the meantime if anyone can recognise this behaviour or if someone has the first clue what to attempt.

Unfortunately, we (still) do not have one of the laptops in question to do our own testing.

 


Here is the event log:

Log Name: Application
Source: Application Error
Date: 13/11/2018 13:12:18
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: 46809L.network.local
Description:
Faulting application name: codex.exe, version: 1.8.0.9, time stamp: 0x5b6318c2
Faulting module name: ntdll.dll, version: 10.0.17134.254, time stamp: 0xbf2f8c99
Exception code: 0xc0000006
Fault offset: 0x00062c3d
Faulting process id: 0x9c0
Faulting application start time: 0x01d47b3c53038bee
Faulting application path: P:\LocalTrade\codex.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: c31b17f6-773e-4964-90ec-bd4736d322c6
Faulting package full name:
Faulting package-relative application ID:

 

 

 

Comment
  1. Vlad V.
  2. Tuesday, 16 July 2019 12:27 PM UTC
Hi Brenton,



I'm afraid to say - no. In fact, just the other day, Appeon Support contacted me to ask if there were any news on this too.

I'm afraid that our client took a highly unsatisfactory decision to run our PB application via remote desktop connection to the server, as on the server, it is working faultlessly.



For a while I was hoping it is just some issue with one clients' network setup or a line of laptops. Our other clients are experiencing nothing like this. Can you provide some more information on how it looks in your instance? How many clients, on what sort of hardware, etc?



Thanks
  1. Helpful
  1. Brenton Scott
  2. Tuesday, 16 July 2019 23:15 PM UTC
Hi Vlad,

Windows Server 2016, Client PC's Windows 10 Pro HP Elite, Webroot Secure Anywhere Virus Scanner. There are only about 6 PC's on the network that use our applications, 4 of which use the apps. heavily and they seem to experience the issue. We have many clients that use our software that don't have this issue. Very (very) occasionally we may hear of a Fatal Disk Error but I am pretty confident this would be because of a network issue.

We have also tried the RDP solution however the feedback was the issue still occurred. I might revisit this plan of action knowing that it worked for you. It is interesting that as you have reported this, it is exactly the same symptoms and we have taken exactly the same course to rectify (from PB11 to PB17). Our issue seems to occur the most when clicking back to the application. BTW - Appeon contacted you on our request.
  1. Helpful
There are no comments made yet.
mike S Accepted Answer Pending Moderation
  1. Tuesday, 16 July 2019 13:52 PM UTC
  2. PowerBuilder
  3. # 6

"FATAL DISK ERROR" is usually (99%) due to running your application from a network drive rather than locally.

Comment
  1. Vlad V.
  2. Tuesday, 16 July 2019 14:34 PM UTC
Hi Mike,



Yes, out of those two errors, "FATAL DISK ERROR" is the more benign one - I believe that is just down to the database being hosted on a network server (application was very much installed locally).



But those two are completely separate - it is the silent crash that is really really worrying.
  1. Helpful
There are no comments made yet.
Brenton Scott Accepted Answer Pending Moderation
  1. Monday, 29 July 2019 10:18 AM UTC
  2. PowerBuilder
  3. # 7

Hi Vlad

I believe I have found the solution to the Fatal Disk Error.  The issue is with the network card setting.  Windows 10 turns on Power Saving mode, which when no activity drops the network connection and doesn’t reconnect quickly enough. Turned off this setting and no issues for a week.

Hope it works for you.

Brenton Scott 

Comment
  1. Vlad V.
  2. Monday, 29 July 2019 13:37 PM UTC
Hi Brenton,



I see - thanks very much for the tip. I'm presently on holiday, but I will certainly check this out once I'm back in the office.



Just to see if I understand it correctly - you simply put the Power Settings profile to something other than Power Saving, or is there a more precise settings that addresses the network card setting that can be switched on or off?
  1. Helpful
There are no comments made yet.
Roland Smith Accepted Answer Pending Moderation
  1. Monday, 29 July 2019 10:30 AM UTC
  2. PowerBuilder
  3. # 8

Seemingly unexplained aborts where the app just disappears could be caused by an incorrectly coded call to an external function - some Windows API function for example.

 

Comment
  1. Vlad V.
  2. Monday, 29 July 2019 13:39 PM UTC
Hi Roland,



Yes, Chris had the same thought, but our entire system has only one call to external function, and that is 100% switched off (by parameters) from being executed for the said client. So I really don't believe that is the case.



In any case, we have other clients on Windows 10 that are not reporting any issues. It is just one network, one set of laptops on Windows 10.
  1. Helpful
There are no comments made yet.
Vlad V. Accepted Answer Pending Moderation
  1. Monday, 19 August 2019 08:24 AM UTC
  2. PowerBuilder
  3. # 9

Hi Vlad

I believe I have found the solution to the Fatal Disk Error.  The issue is with the network card setting.  Windows 10 turns on Power Saving mode, which when no activity drops the network connection and doesn’t reconnect quickly enough. Turned off this setting and no issues for a week.

Hope it works for you.

Brenton Scott 

 

Hi Brenton,

Sorry to bother you, but can you put down some more details about exact power settings that you tweaked on your Windows 10 clients to get rid of this issue?

Also, has this also resolved for you the "silent crash" (error in ntdll.dll) or just Fatal Disk Error? I'd be very surprised, but also very glad.

 

Thanks

 

Comment
There are no comments made yet.
Tomas Beran Accepted Answer Pending Moderation
  1. Friday, 21 April 2023 12:47 PM UTC
  2. PowerBuilder
  3. # 10

Hi

my experience from catching bugs of this kind:

- Never use Show() and Hide(). Set the property directly instead. Especially in menus.

- Never run any code in Window Open event. Don't manipulate with menus,  or visual objects here. Especially data retrieve here is toxic. Only CREATEs and PFC settings should be there. Call other code through POST.  Like:

In window open event:

if ( of_set_resize( TRUE ) > 0 ) then

  inv_resize.of_register( dw_1 , 0 , 0 , 100 , 100 )

  ...

end if

PostEvent("ue_init")

 

In ue_init event:

if ( IsValid( this )) then //this check is important because the window can be rendered incorrectly, PC is turning off etc.

  dw_1.retrieve()

  ...

end if

 

- On the client's computer switch from minidump to full dump https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps

(HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\Windows Error Reporting\LocalDumps\YourApp.exe for 32bit)

- Install windbg preview from MS store

- Download symbols for MS libraries https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-symbols

- Open the fulldump, go to the affected DLL, check stack and look at functions there.

Next because PB symbols are not public you have to just guess what can be source of your issue.

 

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.