Good evening everyone,

For the past week or two I have been experiencing the dreaded “NTDLL,” error with the exception code being 374 indicating a stack hash error. I have followed the CTD guide Jim put together to a T and have had no luck. What’s weird about this, is that it only happens in Europe. I have deleted my P3D.cfg and deleted my shaders. To eliminate a settings error I attempted a flight with the default settings the new P3D.cfg set. I experienced the NTDLL CTD eliminating a high settings problem. I have set my bios to default values, reinstalled P3D more times then I can count and ran the sfc/scan now on the command prompt. I do not run an overclocked graphics card and do not use my traffic. The addons I am using is AS for p3dv4, PMDG ngxu, fslabs (all buses) orbx global, orbx North America LC and some fly Tampa airports. The CTD is most prevalent with flytampas EHAM.  

 

-Scott

Edited January 16, 20206 yr by Scott Albrecht

Scott,

The actions you took above are known fixes to the ntdll.dll and StackHash with Exception Code 374.  Members here on AVSIM and at other flight simulator websites used one of the actions you mentioned and it fixed their problem.  One action you did not take (or at least you did not mention) is deleting the two dll.xml's located in P3D as the dll.xml loads modules and one of those modules may not be compatible with one or more of your products.  I explained recently what happened to me when I get the ntdll.dll error at a payware airport in heavy weather (my comments are the last in the topic but, for some reason, the link loads at the topic beginning which is a bug.  Sorry about that!) -

Here is how to disable the dll.xml(s):

Move or rename the dll.xml.  Default is in same folder as the scenery.cfg but look for one in the same folder as the P3D.cfg as some developers still use this location (Prepar3Dv4 users and higher only; P3DV3 and lower are still located in the same folder as the P3D.cfg). Rename both to dll.off (the one in the same folder as your scenery.cfg will be created as the default config when you restart P3D as this is the new default location). 

Here is how to disable the dll.xml(s): The fact you indicated the CTD's happen mostly around FlyTampa's EHAM is a clue in your investigation.  When you disable EHAM in the Addon Organizer, does this fix the problem?

1 hour ago, Scott Albrecht said:

and do not use my traffic.

This happens with ALL AI traffic programs, including UTLive (which installs many aircraft from MyTrafficX with permission of the developer).  Freeware AI programs are vulnerable too.

I wish there was one specific fix for the ntdll and StackHash errors.  Almost all CTD's in P3D/FSX have no one fix.  You have to investigate.

Hope this helps.

 

45 minutes ago, Jim Young said:

Scott,

The actions you took above are known fixes to the ntdll.dll and StackHash with Exception Code 374.  Members here on AVSIM and at other flight simulator websites used one of the actions you mentioned and it fixed their problem.  One action you did not take (or at least you did not mention) is deleting the two dll.xml's located in P3D as the dll.xml loads modules and one of those modules may not be compatible with one or more of your products.  I explained recently what happened to me when I get the ntdll.dll error at a payware airport in heavy weather (my comments are the last in the topic but, for some reason, the link loads at the topic beginning which is a bug.  Sorry about that!) -

Here is how to disable the dll.xml(s):

Move or rename the dll.xml.  Default is in same folder as the scenery.cfg but look for one in the same folder as the P3D.cfg as some developers still use this location (Prepar3Dv4 users and higher only; P3DV3 and lower are still located in the same folder as the P3D.cfg). Rename both to dll.off (the one in the same folder as your scenery.cfg will be created as the default config when you restart P3D as this is the new default location). 

Here is how to disable the dll.xml(s): The fact you indicated the CTD's happen mostly around FlyTampa's EHAM is a clue in your investigation.  When you disable EHAM in the Addon Organizer, does this fix the problem?

This happens with ALL AI traffic programs, including UTLive (which installs many aircraft from MyTrafficX with permission of the developer).  Freeware AI programs are vulnerable too.

I wish there was one specific fix for the ntdll and StackHash errors.  Almost all CTD's in P3D/FSX have no one fix.  You have to investigate.

Hope this helps.

 

Thanks for the response Jim, I’ll try that xml advice and report back. Since you have great knowledge on this, would you have an idea why it only happens in a certain area?

Also if renaming the DLL.xml files to dll.off works, I assume I can leave it that way? I guess what I’m asking is what exactly are those dll’s and what does turning them to “off,” do? 

35 minutes ago, Scott Albrecht said:

Also if renaming the DLL.xml files to dll.off works, I assume I can leave it that way? I guess what I’m asking is what exactly are those dll’s and what does turning them to “off,” do? 

No.  If it fixes the problem, then you will have to find out which module caused the CTD.  The AVSIM CTD Guide has images and guides on how to disable each module in the dll.xml.  See page 14.

1 minute ago, Jim Young said:

No.  If it fixes the problem, then you will have to find out which module caused the CTD.  The AVSIM CTD Guide has images and guides on how to disable each module in the dll.xml.  See page 14.

That is my next step then because that was the problem! I renamed them both to “off,” and flew a complete flight from EHAM to EKCH without a CTD. Thanks for all the help I really appreciate it. Just curious if I can’t narrow down the module what will leaving them both “off,” do to P3D?

When I went to check, it looks like P3D rebuilt both xml files when I launched it for the previous flight. I now have both dll.xml and the ones I named dll.off in both appdata/roaming and where the scenery.cfg is located 

Edited January 17, 20206 yr by Scott Albrecht

This is all thats in the dll file, doesnt look as extensive as the one in the guide.

<?xml version="1.0" encoding="UTF-8"?>
<SimBase.Document Type="AceXML" version="3,0" id="dll">
    <Descr>AceXML Document</Descr>
    <Filename>dll.xml</Filename>
    <Launch.Addon>
        <Name>RAASPRO</Name>
        <Disabled>False</Disabled>
        <ManualLoad>False</ManualLoad>
        <Path>.\RAASPRO\RAASPRO.dll</Path>
        <DllStartName>module_init</DllStartName>
        <DllStopName>module_deinit</DllStopName>
    </Launch.Addon>
    <Launch.Addon>
        <Name>PMDG_Interface</Name>
        <Disabled>False</Disabled>
        <Path>PMDG\DLLs\PMDG_Interface.dll</Path>
        <DllStartName>module_init</DllStartName>
        <DllStopName>module_deinit</DllStopName>
    </Launch.Addon>
</SimBase.Document>

 

First, i would rename the dll.xml in the scenery.cfg location. Just remove the .off. Run your flight again and see if you still have no CTD'S.  If no CTD then you know the faulting module is in the other dll.xml.

P3D default aircraft includes some Carenado aircraft so you should see a couple of entries in the default dll.xml.  If psd crashes then i would suspect the Cmeteo entry. If it crashes just disable it. Not really needed as Carenado uses it as its weather gauge.

18 minutes ago, Jim Young said:

First, i would rename the dll.xml in the scenery.cfg location. Just remove the .off. Run your flight again and see if you still have no CTD'S.  If no CTD then you know the faulting module is in the other dll.xml.

P3D default aircraft includes some Carenado aircraft so you should see a couple of entries in the default dll.xml.  If psd crashes then i would suspect the Cmeteo entry. If it crashes just disable it. Not really needed as Carenado uses it as its weather gauge.

Got it, since renaming the original dll.xml's to off, letting them rebuild and monitoring I have had no ctd's. Thank you for the help. I can report as of now at least lol, all is stable.

I am confused though as to why my dll.xml has such few entries and for the life of me I cannot find that Carenado radar anywhere in them. Welp I essentially forced P3D to rebuild both dll.xml‘s by naming them both “off,” and that fixed all my CTD’s. Maybe that’s another work around to be included in the ever helpful CTD guide. I know it says to narrow the faulting module down but my xml’s only show RAAS, PMDG and FSUIPC. Oh well the CTD’s are gone so I won’t complain about how it weirdly worked for me just renaming them off and letting them rebuild. Thanks Jim for the help I greatly appreciate it. Guess you can mark this thread as closed and solved 😄

The only dll.xml that will rebuild is the default in the same folder as your scenery config. The one in the same folder as your p3d.cfg will not be rebuilt. If youdo not see any Carenado entries then you need to install the Content part of P3D. That may be correct and just guessing. If there are no Carenado entries then that may be good.  The main p3dv4 directory should contain the  Carenado entries.

Yea it’s quite strange the only thing in both my xml’s are “acexml,” that P3D rebuilt. I still have both dll.xmls renamed to off then they got rebuild. Now when I open both the new ones it just says “acexml=active.” No CTD’s for the past 15 flights anywhere in the world. Maybe it’s just a weird fix that worked for me. I’m thinking tho fsuipc has something to do with the crashes but can’t prove it. Can’t narrow any modules down since both xml files just read “acexml,” now and nothing else. I have content, scenery and client all installed and up to date as well. 

Edited January 18, 20206 yr by Scott Albrecht

This is what both my xml's say:

 

<?xml version="1.0" encoding="UTF-8"?>

-<SimBase.Document id="dll" version="3,0" Type="AceXML">

<Descr>AceXML Document</Descr>

<Filename>dll.xml</Filename>

</SimBase.Document>

When you first purchase P3D, the installation program will install a dll.xml and place it in the same folder as your scenery.cfg.  There will be nothing in it other that the header at the top.  . Lockheed Martin put it there so that add-on developers could use it to place an entry for their modules so the modules would load at startup of P3D.  The FSUIPC module is one of them.  When it is installed, they install a new dll.xml and place it in the old default location where the P3D.cfg is located.  ActiveSky places their entry in the old location too.  As you reported above, FSCrew installed RAASPRO in the default dll.xml.  So did PMDG.  It doesn't make any difference which dll.xml is used by an add-on developer but it is preferred they all be located in the default location in the same folder as the scenery.cfg.  The dll.xml creates the Add-on Menu you see when you startup P3D.  When you click on the Add-on Menu, it will show options where you can open up FSUIPC or RAASPRO and make some changes. 

When I told you to backup the dll.xml's and rename them to dll.off, this effectively stopped the loading of any modules when you first start up P3D. When you start up P3D, it creates a new default dll.xml and there is nothing in it other than the header information at the top you mentioned.  There is no new dll.xml created in the same folder as the P3D.cfg.  You can go into that folder and rename dll.off by just removing .off.  This will allow the FSUIPC and ActiveSky entries to be loaded again.  You can then do another flight and see if the crash occurs again.  If it does, then your suspicion that FSUIPC may be at fault may be correct.  In that case, you would have to go to the FSUIPC site and see if there is an update, download, and install it.  But first, you want to run a flight and see if you get a CTD.  If not, then it is not the fault of the FSUIPC or ActiveSky. 

You will have to delete the new dll.xml created in the same folder as the scenery.cfg.  Once done, rename the dll.off by removing .off.  This will activate the entries in this dll.xml.  Run the flight again and see if you get the crash.  If so, then you know one of the modules in this dll.xml is causing the crashes.  You do this by opening up dll.xml using Notepad so you can edit it.  Here is one of your entries:

<Launch.Addon>
        <Name>RAASPRO</Name>
        <Disabled>False</Disabled>   This is the line you edit.  Change False to True such as  <Disabled>True</Disabled>
        <ManualLoad>False</ManualLoad>
        <Path>.\RAASPRO\RAASPRO.dll</Path>
        <DllStartName>module_init</DllStartName>
        <DllStopName>module_deinit</DllStopName>

After you edit as above, this module will no longer load when you start up P3D.  When you run the flight again, if there are no crashes, then you know RAASPRO was the culprit.

Hope this helps!

Best regards,

Jim