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.

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

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.

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 

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

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:

 

 

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.

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

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

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