Register Dll Entry Point Not Found

[Jessia Adachi]

Iam a beginner and I am trying to use MSIX Packagin tool. So I started with creating a msix package for 7zip. I downloaded the exe from -zip.org/download.html, and specified the location in select installer. I am using self-signed certificate. When the installation completes, it moves to First Launch tasks step and there it does not show any entry point for the specified installer. When I try to browser dialog displays message - we did not detect any new entry points. Run your installer and try again. If I continue to creating package, generated MSIX package is only 19KB in size.

@Sigmarssonthanks for your reply. To use makeappx.exe tool I would need to create AppxManifest.xml file. So I tried following this link -us/windows/msix/desktop/desktop-to-uwp-manual-conversion to create xml file. So before packaging I tried to test the application. I ran the add-appxpackage command but its giving following error:

@krathore As to the error code, I suspect that you have a remnant of a previous attempt and cannot add what the system believes to be the same package twice. Try running get-appxpackage -AllUsers as well as get-appxProvisionedPackage (with and without the -online option).

Generically, capturing 7Zip in the Microsoft MSIX Packaging tool should find the entrypoint just fine. I package that app using the FileRedirectionFixup to solve some file write issues, and find that OS 2004 is needed to solve a registry issue. There is still a small loss of functionality with shell extensions, but the app mostly works.

If the tool is not showing the entry point that means it did not detect the executable file being created while it monitored the installer. This can happen if the application you are packaging (7zip) is already installed in the machine before you create the package with the MSIX Packaging Tool. We recommend you package your applications in a clean machine or VM to prevent that.

If the application is already installed before packaging, the package you create will probably be almost empty. You could confirm this by opening it with the Package editor available in the tool and exploring the files in it.

Although I don't think any of these is the case here, the entry point may also not be found if the installer fails (so the executable file is not created), if there is no shortcut created to it (it would show up in the browse dialog to add it), or if you are installing to a different disk drive than the specified install location.

The error says the function BTICard_CISWr is missing in the dll. You can open your dll using depends.exe and find if the dll really contains the function. One more thing you may like to check could be the version of the dll.

The person who previously worked on this project gave me all the files for this project. On his computer it does not flag this error. Looking at his BTICard.dll, that also does not have the function BTICard_CISwr@16. so why is this error getting flagged for me.

The missing function name can be BTICard_CISWr........(...). I mean starting with "BTICard_CISWr". The error message is not fully descrbing the missing function. So Use depends.exe (downloadable from net) to find out the exact missing procedure (function). You will find a red line for the missing procedure.

The original developer's system might be finding a different version of the DLL that does have the entry point. Or, there's a bad version of the DLL on your system that the OS is loading despite your building a "good" version.

It can be perverse trying to ensure the OS finds the specific DLL you want, since the DLL searchpath (the "LoadLibraryEx" function, essentially) varies by OS. One way to be certain is to put the DLL in the same folder as the executable, as all of the search paths implemented by Microsoft include the executable folder as the first place to look. I've been burned many times thinking I'm debugging the DLL I just built, only to find that the OS is loading and using an older version it's finding somewhere on the system.

I am in the habit of simply deleting every copy of a DLL I'm debugging to ensure the OS loads the version I've just built. Using the versioning (DLLGetVersion) helps at runtime, but only if you implement the DLLGetVersion method in your DLL, which isn't necessary to make a DLL work but it helps you do a dynamic (i.e. runtime) check of the version. At app startup I always call DLLGetVersion on the DLL's I've created so as to log the version used. It can be a trick to implement the DLLGetVersion method the way Microsoft says but it can be done, I have code for this if you like. If you do this, then you can increment the DLL's build number each time and differentiate your DLL from build to build. CVI will autoincrement the build for you if you tell it to.

Also, if you have the DLL project in the same workspace as the application that's calling it, CVI won't automatically switch the DLL export library and the DLL from debug to release for you when you switch the executable.

from release to debug and visa versa (assuming you've done a debug and release version of the DLL). This is another way to get fooled - you've built a debug version of the DLL but the app is still binding to an older, release version.

I'm trying to reverse proxy to my wireguard setup on another local server. I'm having issues with the entryPoint of the router. I'm trying to setup wireguard.domain.com:58120 to route to LOCAL_IP:51820

In the logs I read this line: level=debug msg="Start UDP Server" entryPointName=wireguard which made me realise that I've been creating a UDP entrypoint but an http router and service this whole time. I modified app-wireguard.toml as follows:

One of our uses Visual Studio 2019 Community and Intel oneAPI Base+HPC Toolkit. He modified one of the subroutines and recompiled its DLL file. When he rerun the program with the updated DLL, he got the following error message:

In the future, how do we prevent this kind of error? Our compiler and our users' compiler will always be different.

This means that our compiler could be an older or newer version compared to the ones of our

users.

It is a general rule that the run-time libraries be at least as new as the version the application was built with. Intel provides free downloadable installers for the compiler libraries. However, DLLs you build with an old version should continue to work - unless...

Unless you did something very bad and either provided outdated Intel compiler library DLLs or, worse, built your DLL with the Intel libraries linked in and with the symbols exported, so that the user's code is looking for Intel entry points in your DLL. I really hope you're not doing that, but I've seen it before.

The more likely answer is that you installed the 2012 DLLs along with yours, not using the Intel redistributable installer, and Windows found them in PATH before the correct ones. It may be that there are multiple copies of libifcorert.dll on the user's system - the correct ones and the ones you provided, and PATH has both folders but the wrong one first. The old Intel DLLs should be removed and PATH edited to point to the ones installed by the compiler.

That Windows is looking for that entry point in newmodes.dll suggests to me that the "very bad" situation I described is in fact what happened. There's no good reason for Windows to be looking for for_realloc_lhs in newmodes.dll. Is that your DLL?

After I compile the DLL file, where can I find the link map and how do I know if this is correct? Our user compiled the DLL file and got the error message. I need to understand it before I give him the instruction. Thanks you

In your project Property Pages, navigate to Linker-Debugging, and set "Generate Map File" to "Yes". You can give the map file a name of your choosing, or accept the default name. Alternatively, in the Linker-Command Line panel, add /map .

Attached are two map files from our user. We distribute our main app with several DLLs that our users can modify on their own. When our user modified GEOMXACT.DLL, it works with our main app. However, the error message is from their modified NEWMODES.DLL with our main app. Our user says that he uses the same procedure to compile these two DLLs.

Only one of the two map files shows an entry for the RTL routine for_realloc_lhs. Old versions of libifcoremd.dll did not export for_realloc_lhs. Steve_Lionel's diagnosis probably applies, if you substitute "libifcoremd" for "libifcorert".

On the system where the "for_realloc_lhs ... not found" message is issued when your application is run, check the execution path and make sure that the new libifcoremd.dll is found in %PATH% before the old version.

We distributed the main app and three *dlls, including newmodes.dll and geomxact.dll. The user runs the apps without any issues. Then he recompiles these two dlls to fit his needs. Both dlls are compiled in the same environment.

When he replaces our geomxact.dll with his updated geomxact.dll, the app runs OK. But when he uses his newmodes.dll, the app runs with the error message. How can one of the dll map shows an entry for the RTL routine for_realloc_lhs but not the other?

3a8082e126