Ntdll.dll
Kathrine Selvage
I have an application that I've written that crashes intermittently, but I'm unable to capture an exception at the application layer. I always get an entry in the event log but doesn't give me much info:
Update: I've gotten to a point where the application crashes on startup with the above reason. It gets to the end of the MainWindow constructor (it is a WPF application), sits there for about 10 seconds on a white screen and then dies. I've rolled back to older versions of the software and reproduced this behavior. I have also moved it to another machine and did NOT see this behavior, so my current theory is in agreement with what was said in the comments - that something corrupted the heap and it only gets cleared up on a reboot.
So that's what I'll be hunting today. Interestingly and disturbingly enough, the app crashes every time on startup, even after rebooting. The same behavior does not occur on other machines at this time.
The last time I had a similar crash in my app that pointed to ntdll.dll as the faulting module, the reality was that my own code had a memory leak. I did a strcpy on a string that was not allocated memory. Something like,
If you are experiencing an app crash with Faulting module name: ntdll.dll, there are a few steps you can take to try and fix the issue. First, try running a System File Checker scan to repair any corrupted system files. You can also try running an antivirus scan to check for any malicious software that may be causing the issue. Additionally, try updating your drivers and any applications that are related to the issue. If these steps do not help, you may need to reinstall the application or contact the software developer for additional support.
I think the better option here is to reinstall the windows OS and then reinstall the applicaitions and then see if the error is still there. If it is, buy a new computer and try again. If the the error is still there, find a workaround for it. ;-)
Hi, I have a very similar problem and want to make sure one thing to not ruin my Windows 11 installation.In my case ntdll.dll 10.0.22621.1485 causes an error on my personal PC whan I run an .exe, program, which I re-installed and runed in different ways in different compatibility modes with no success: same error occurs. If I downgrade ntdll.dll to a 10.0.19041.423 Version, is that fatal? ntdll.dll is an essensial file to run Windows properly. I have just to manually give the "Trustinstaller" the rights back to run it properly after rebooting my PC, after replacing it in the System32 folder, right?
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
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:
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.
- 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:
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.
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.
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.
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.
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.
4a15465005