Couatl64_P3D.exe - Entry Point Not Found **WINDOWS 7 is no longer supported**

[virtuali]

The problem arose yesterday after updating, the backup was from last sunday, the FSDT files with date 6 feb version work. If I can help further, please tell me

Maybe you missed my explanation. We know what file likely broke compatibility with Windows 7, it surely is the latest versions (32 and 64 bit ) of the two Couatl executables, which are required by the update.

It's not as if we flipped a switch saying "kill Windows 7 compatibility" when we compiled it. It's just that, in order to compile an .exe which includes all the latest security fixes from Microsoft that comes down automatically as Visual C++ libraries updates that matches the same security updates that are released to users, which are not coming anymore for Windows 7.

And we MUST do this, to have a product that works reliably on the *supported* OS, because these regular fixes are usually to patch security problems, like exploits that might be dangerous if hackers found a vulnerability in our .exe JUST because we were guilty of NOT having kept our compiler up to date, just to be sure we could continue supporting legacy OS.

Any of these updates would cause to release a version of the executables that might have broke compatibility with Windows 7, it could have happened at any time, you have just been lucky it never happened earlier, but sooner or later it would have happened, and the only reason for this is your assumption that you could continue to use an unsupported OS years after its official EOL without any consequences to software that is still supported, so it's updated very often.

[Broeder Alarm]

Thanks for the " not support" for  windows 7 users, till thuesday it was fine working, what was the reason for change of the installer. (and no warning before) and not "for 2 years"

 Is would be better to make different versions of the installer

You are the maker of the software and not Microsoft, look to NVidia they make different versions for the OS.

Well you force me to change to Windows 10, I hope that you realize what you saying.

Grt. from a very disapointed (win 7) user.

[virtuali]

Thanks for the " not support" for  windows 7 users, till thuesday it was fine working, what was the reason for change of the installer. (and no warning before) and not "for 2 years"

It doesn't seem you understand my explanation.

Is not that we made this on purpose so no, there's no "reason" on our part, it might have happened because we MUST keep all our compilers updated so, whenever we release a new version of the executable, it will benefit from all the updated libraries that will make the application more reliable with today's OS.

Is would be better to make different versions of the installer

No, because that would imply some kind of "support" on our part, something we HAVE alerted users since January 2020, when Windows 7 went completely out of support. To do a separate release for Windows 7 would imply being able to TEST the software and being able to SUPPORT Windows 7 users, and actually carry over extra development costs, higher monthly bandwidth costs to keep a separate installers, which in our view is not worth to support an handful of users that WILL eventually upgrade to a new OS.

We already saw these kind of arguments some years ago, when sometime, one of the Windows 7 updates broke compatibility with our software, so we had the complains by Windows XP users saying they will "never" upgrade. Of course, nobody is still asking to keep a "different installer" for XP anymore.

You are the maker of the software and not Microsoft, look to NVidia they make different versions for the OS.

I never said it's "impossible" to make a Windows 7 version of a software. nVidia surely has the resources to afford the cost to support a legacy OS, the Flight sim market is just too small to do that.

Well you force me to change to Windows 10, I hope that you realize what you saying.

You should have switched to Windows 10 2 years ago, not now. And we have been saying this to Windows 7 users over and over since then, you seem to have assumed that, if it worked so far, it would work forever, but that's a risky assumption to make, when the developer is telling you Windows 7 is no longer supported.

And no, we are not forcing you to update to Windows 10, you can still stay with the previous version, provided you kept the previous installer, something you should do for all your current applications, because it's very likely a Windows 7-compatible version of any of your other apps might disappear sooner or later.

As I've said already, if you run an older installer with the network disconnected, it will work with that version, just you won't be able to UPDATE again so, you would be exactly in the same situation MICROSOFT has already put you 2 years ago: no more Windows Updates for Windows 7 and no more support.

[achmedfsx]

I understand you cannot keep a Windows 7 for testing at your site and with P3D 4.5 HF2, I will remain unsupported too some day, not only from FSDT...

But at the moment, I have a rock solid simulator environment without crashes, without re-installing any application (not only the simulator environment),
without spending most of the time in fiddling on the system instead of flying - so I hope, you understand my displeasure to upgrade my "simulator rig" to Windows 10.

For me, the fallback was easy as I take always (good old) Ghost image backups before I start bigger changes on my systems.
So I will not update GSX further, that's also easy for me as I fly mostly small GA.

But I would expect that you look at the error message, as you're an experienced person, maybe there's an easy fix.
If not, I have to accept and stay with the actual GSX level - and maybe someone else find a solution and posts it here.

[Lefuneste]

Same disappointment to can't continue to use GSX ! we don't ask here to have always a supported version even on old OS. We just want to stay with the last availlable working version. P3D switch to a V5. No problem we still fly with a working version of P3DV4.5 HF3. FSX continue also to work with the SP2. We know now versions after january 2022 are ko for the windows 7 users. it's probably simple to have a fix (last version for windows 7) in order to let the users having a simple choice : to continue to have updates with a supported OS or to fly with a final version for win7. my point.
C.M.

[achmedfsx]

Just what I did the last hours:

I updated the Visual C++ Redist x86 and x64 to 2015-2022 redist according to website https://docs.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170 (support from Vista onwards !).

After the first update (x64), the desktop icons disappeared, so I started the task manager by Ctrl-Alt-Del, started "cmd" from there and rebooted by shutdown /r, all icons were back.

Then I renamed the FSDT folder from yesterday's update and run the FSDT Live Update again.
Now, the error message appears again, but P3D (4.5 HF2) starts, XPOI shows it's arrows and I can order a GSX ground vehicle.
I'm not sure if the Visual C++ Redist update was necessary...

BTW: I have no knowledge of MS Visual, but I checked the library "api-ms-win-downlevel-ole32...dll" with dependency walker.
This dll never had an entry point "GetErrorInfo.". In Win 10, I couldn't find this dll by searching at all, so I think this dll isn't the reason for the error message but just some kind of last resort while searching for the entry point.

I found this entry in the MS documentation for oleauto.h that points to library OleAut32.dll (and other libraries, but the library mentioned in the error message is also related to OLE).

Now OleAut32.dll offers this entry point (Win 7 + 10). OleAut32.dll is further related to Ole32.dll, in tis lib I found the same entry point "GetErrorInfo". So the problem of the missing entry point must go deeper (as the official Win 7 OLE lib offers this entrypoint, assuming GSX is using this one).

Then I found information about similar error messages related to program linkage modes.
https://docs.microsoft.com/en-us/cpp/build/linking-an-executable-to-a-dll?view=msvc-170
I found hints that "entry point not found" could result from a wrong linkage mode.
So just a thougt that one of the GSX updates of the last two weeks brought such a wrong linkage,
maybe with a fixed dll name of Win 10 that is not the same as in Win 7 ?
Just an assumption...

[virtuali]

BTW: I have no knowledge of MS Visual, but I checked the library "api-ms-win-downlevel-ole32...dll" with dependency walker. This dll never had an entry point "GetErrorInfo.".

I made some research too and, it's entirely normal YOUR version of that dll won't include it. All of your with that error have the api-ms-win-downlevel-ole32-l1-1-0.dll listed of missing that function but, according to this Microsoft page, which specifically discusses Legacy Desktop OS, indicates the GetErrorInfo is supposed to be included in the api-ms-win-downlevel-ole32-l1-1-1.dll

https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/mt588480(v=vs.85)#api-ms-win-downlevel-ole32-l1-1-1dll

As you can see, GetErrorInfo is there. I don't know when this updated version came out and how to obtain it but, as you did, I also checked my whole \Windows folder in Windows 10, and while there is a "Downlevel" subfolder ( both 32 and 64 versions of it ), which contains several .dlls with similar names, THAT specific one isn't there, in any version so, it seems that .DLL is specific to OS older than Windows 10.

Now, it's possible it might belong to Windows 8 or perhaps 8.1, but since when these came out, Windows 7 was STILL fully supported, I would guess it should have been available for Windows 7 as well, during one of the Windows updates, when they were still up.

Today, I can't see how you could possibly get it, other than with a redistributable runtime, which you did and seemed to have improved the situation.

[olseric]

As I've said already, if you run an older installer with the network disconnected, it will work with that version, just you won't be able to UPDATE again so, you would be exactly in the same situation MICROSOFT has already put you 2 years ago: no more Windows Updates for Windows 7 and no more support.

Where would we find these older installers cached on our machine?  I have the original from when I purchased it, but having a "live update" software pretty much negates the ability for me to go out to your website to download it.  Nice feature, don't get me wrong, but eliminates the ability to "roll back" when something goes wrong.

I tried the trick presented by achmedfsx.  I still get the error on startup and the GSX application is not loading (no jetways at any "default" airport either which I presume is a function of GSX).

[virtuali]

Where would we find these older installers cached on our machine?

When you download the installer, at the end of the installation it will ASK YOU if you want to KEEP the installer you just downloaded in the Documents\GSX_Installer folder. The Document folder has been chosen under the assumption ANY user SHOULD do REGULAR Backups of his own Documents folder.

In never had a regular backup strategy, not even for your own Documents folder, that's even more reckless than still using Window 7 in 2022.

I tried the trick presented by achmedfsx.  I still get the error on startup and the GSX application is not loading (no jetways at any "default" airport either which I presume is a function of GSX).

You must fix the startup error and, as far as I know, the only way to fix it is getting hold of the updated api-ms-win-downlevel-ole32-l1-1-1.dll, because the function we use must have been moved there, so it's not present anymore in the api-ms-win-downlevel-ole32-l1-1-0.dll you have. This .dll is NOT present in Windows 10, so it must have appeared somewhere as an update to Windows 7.

[achmedfsx]

I made some research too and, it's entirely normal YOUR version of that dll won't include it. All of your with that error have the api-ms-win-downlevel-ole32-l1-1-0.dll

Sorry, I don't have much knowledge of the MS Visual environment. But I ask myself if the call has to be done to ms-win-downlevel-ole32 directly. What I understand: you want to get the error object from COM, so you call GetErrorInfo.
But shouldn't this call be done through ole32.dll (this dll contains an entry GetErrorInfo in Win 7: http://www.win7dll.info/oleaut32_dll.html) ? Isn't this the function we talk about: https://docs.microsoft.com/de-de/windows/win32/api/oleauto/nf-oleauto-geterrorinfo?redirectedfrom=MSDN ?

Now, it's possible it might belong to Windows 8 or perhaps 8.1, but since when these came out, Windows 7 was STILL fully supported, I would guess it should have been available for Windows 7 as well, during one of the Windows updates, when they were still up.

If I understand it right (excuse my dumbness), according to https://www.nirsoft.net/dll_information/windows8/combase_dll.html, in Windows 8 the oleaut32.dll exposes GetErrorInfo (too), and imports CoGetErrorInfo from combase.dll.
In my understanding, one has to call oleaut32.dll, from there it goes to combase.dll (Win8).

Is my assumption total nonsense ?
If no, I ask myself why the resolution doesn't find the entry in oleaut32.dll after the update(s) of the last two weeks in Win 7.
Maybe I have to set some kind of a LIBPATH (as in UNIX) ?

[achmedfsx]

By the way: https://support.microsoft.com/de-de/topic/kompatibilit%C3%A4tsupdate-um-windows-7-auf-dem-neuesten-stand-zu-halten-5fe4a218-adf1-9074-9522-bea956cf149b mentions Api-ms-win-downlevel-ole32-l1-1-1.dll 10.0.14393.0 from 22-Jan-2018. Not sure if I get it (maybe for enhanced support - entrprise customers - only ?).

[virtuali]

Have you tried downloading from the Catalog link ?

https://www.catalog.update.microsoft.com/search.aspx?q=kb2952664

[olseric]

You must fix the startup error and, as far as I know, the only way to fix it is getting hold of the updated api-ms-win-downlevel-ole32-l1-1-1.dll, because the function we use must have been moved there, so it's not present anymore in the api-ms-win-downlevel-ole32-l1-1-0.dll you have. This .dll is NOT present in Windows 10, so it must have appeared somewhere as an update to Windows 7.

I tried that as well.  I plugged the 1-1-1 version into Windows and it was still calling the 1-1-0 version.  I even went a step further renaming 1-1-1 to 1-1-0 to see what would happen.  The error went away, but GSX wasn't loaded properly in FS (showed that I needed to activate it, Coautl not running, etc).

I'll hunt for the older installers now that I know where to seek.

Have you tried downloading from the Catalog link ?

https://www.catalog.update.microsoft.com/search.aspx?q=kb2952664

I'll try that as well and report back.

[achmedfsx]

Before downloading KB2952664, I did a "wmic qfe list > qfelist.txt" and opened qfelist.txt with notepad.
-> http://support.microsoft.com/?kbid=2952664     AH3     Update                        KB2952664               NT-AUTORITÄT\SYSTEM  7/12/2018
It was an update for Win 7 telemetry, the libraries are in folder C:\Windows\System32\CompatTel.
The last minutes, I tried some steps similar to olseric's :
- put C:\Windows\System32\CompatTel at the end of my PATH environment variable (system properties - advanced system settings - environment variables)
- put the library api-ms-win-downlevel-ole32-l1-1-1.dll into folder C:\Games\FSDT\Addon Manager\couatl64 (where couatl64_P3D.exe resides here)
- renamed it there to api-ms-win-downlevel-ole32-l1-1-0.dll
but it will not be taken.
- I didn't copy it to windows\system32 as I feared to destroy my system completely.
- I didn't try to "register" this dll (regsvr), may

Dependency Walker shows the entry point GetErrorInfo in api-ms-win-downlevel-ole32-l1-1-1.dll,
the question is how this library is searched.
I suppose that  GetErrorInfo isn't called directly in api-ms-win-downlevel-ole32...dll but from another library.
I searched the registry for api-ms-win-downlevel-ole32-l1-1-0.dll : no luck, so it may not be searched by "dll registration".
I searched the dll's in windows\system32 and found the text "api-ms-win-downlevel-ole32-l1-1-0.dll" in some dll's,
e.g. wininet.dll or jscript9.dll (dependency walker shows them connected to the mentioned ole32.dll).

That may be the reason why replacing api-ms-win-downlevel-ole32-l1-1-0.dll in system32 by 1-1-1.dll may lead to other errors:
all these api-ms-... and the other (important) dll's seem to reference each other in a hardcoded way inside each dll.

If this is true, we will not solve the problem without replacing a whole bunch of system32 libs (destroying Windows ?).

[achmedfsx]

Sorry for spaming this thread, but I gave it a last try.
I searched couatl64_P3D.exe for the library name - bingo !

I changed the lib name from ...1-1-0.dll to ...1-1-1.dll in couatl64_P3D.exe
with a hex editor (see the attached image)
while C:\Windows\System32\CompatTel was still at the end of my  PATH envvar.

After P3D started, I got a message that couatl64_P3D has been changed,
I clicked OK and was on Eglin's runway.
I pressed Ctrl+Shift+F12, ordered a car to a gate, the car came.
As it's late here, I have to exit (= go to bed).
No visible error at P3D shutdown (have to look in Win event manager tomorrow).

But why is a hardcoded reference to api-ms-win-downlevel-ole32...1-1-0.dll in couatl64_P3D
as this lib doesn't contain GetErrorInfo as you stated before ?!? Strange !

What makes me wonder:
after I removed C:\Windows\System32\CompatTel  from the PATH,
P3D start leads to "Couatl64_P3D cannot be started as api-ms-win-downlevel-ole32-l1-1-1.dll is missing on this computer".
But in P3D, I see the addon menus of GSX and XPOI.