I have a really vague problem, but I hope someone can help with it. I was modifying a C++ project and yesterday it was still working, but today it's not. I'm pretty sure I didn't change anything, but to be completely sure I checked the project out from SVN again and I even reverted to a previous system restore point (because this is a work computer, it sometimes secretly installs updates etc.). After succesfully compiling it, the program can start up, but after I interact with it, I get this error:The procedure entry point ?methodName@className@@UAEXXZ could not be located in the dynamic link library libName.dll.
I've searched the internet, but most people's problems seem to be caused by an older version of the DLL being used. I searched my computer and there is no older version. If I delete the correct version, the application doesn't start. If I then recompile the project, the DLL is created again, so I'm both pretty sure that the application is using the correct DLL and that the compilation is creating it. If I introduce syntax errors into the method that the error refers to, the project refuses to compile, so I guess this means that it is also compiling the files that contain the method.
Basically I don't know anything about DLL's, linking, etc. so I would greatly appreciate it if anybody has an idea as to why the functions that are very clearly defined in the project are all of a sudden not making it into the DLL anymore. I know this is vague and if any more information is required I will gladly provide it. Thanks!
Update: I have tried the given suggestions, but I'm still stuck. __declspec(dllexport) is apparently not used in the entire project. Opening the DLL with Dependency Walker shows me an empty top right section and the section below it lists the function from the error message. If I check Undecorate C++ Functions it looks fine, but if I don't I get the weird question marks and @s from the error message and there appears to be a difference at the end:
Are you actually using __declspec(dllexport)? My guess is no -- without that declaration, that function will not be exported by the DLL (or in other words, programs loading that DLL will not have access to functions without that declaration).
So that if you have #define MAKING_DLL before that section, all functions that are declared like FOO_API int BakeACake() will be exported based on whether MAKING_DLL was defined. It's possible that the project was expecting MAKING_DLL (or its equivalent) to be defined on the command line, depending on the project type built (something like /DMAKING_DLL; or you might even need to define FOO_API yourself like /DFOO_API=__declspec(dllexport).
The empty top right section in Dependency Walker just means your program isn't linking against the DLL's corresponding .lib file. That's okay, it just means you are using LoadLibrary or LoadLibraryEx to access functions in the DLL.
Another fairly likely scenario (based on the fact that the mangled names are different) is that the program was built using a different version of Visual Studio than 2008, which you used to build the DLL. Unlike plain C, there's no standard binary interface for C++, which means that you have to use the same compiler to build the program and the DLL when you are using C++ classes in the DLL. If you can, try rebuilding the program in VS2008, or try rebuilding the DLL in the same version of VS as the program was built.
Download dependency walker and open your dll using this tool. It will show a list of exported functions from your dll. Check whether the above said method is part of the expected functions. If it's not, then it means you accidentally removed __declspec(dllexport) for one of the classes in that dll.
I feel a bit stupid, but I found the answer. The application (exe) I was using apparently loaded a second, different dll which had a dependency on the one mentioned in my original post. This second dll was still expecting the old functions and also needed to be recompiled against the updated dll.
Using information of the posts above I found simple general solution. All you need to do is open programs executable with dependency walker, look for the missing functions, look what dll's are using it, find the project which builds that dll and rebuild it.
However when our app is launched, it gives a different error message before terminating: "The ordinal 289 could not be located in the dynamic link library C:\Program Files\CompanyName\AppName\WININET.dll." (The customer who reported the original issue was running Win 8.1 64 bit, so that may be why the error message is different.)
The common issue with this and the other message seems to be the inclusion of the NI Internet Library features. I tried building the sample XML project that ships with CVI (no internet functionality) and it installs and runs fine in the Win 8.1 environment.
I am filing a bug report on it with NI and from there the Product Support Engineer might decide to inform Microsoft about it, since it seems like something on their end. I will let you know if there is anything else we can do.
(By the way I see that I did not directly answer your earlier hypothesis about multiple versions of CVI. The problem occurs after deploying just our one app to a clean install of just Windows 8.1, so multiple versions of CVI or the RTE are not the issue. )
I have installed Win 8.1 (x64) RTM and CVI 9.1.1. However, I cannot reproduce either error with an internet library example. Are you able to reproduce this with any of the samples? If not, are you able to send me your project to test it on my system? If you can, I have sent you a private message with instructions on how to send me project.
I have recently received an error message that starts out with "The Procedure entry point XXX Could not be located in the dynamic Link Library" and then I get an Error 7 (Windows error 127). iTunes will not start. I have uninstalled all Apple programs and then re-installed them. Still no luck. I am running Windows 8.1. I have tried systen restore too but with no luck.
There are several different scenarios that could lead up to the error, but typically it arises because an older version of the .dll has been copied into the wrong folder to workaround a different problem, and now after updating iTunes the outdated .dll that gets called cannot handle the request made of it.
The steps in the second box are a guide to removing everything related to iTunes and then rebuilding it which is often a good starting point unless the symptoms indicate a more specific approach. Review the other boxes and the list of support documents further down page in case one of them applies.
It doesn't say what kind of error this is. I've tried installing individually the Apple Application Support and Apple Mobile Device Support items individually, as was suggested elsewhere for a similar error, but with no luck. iTunes still won't open.
Such errors may be fixed by deleting the named file and then repairing the component it belongs to, in this case iTunes itself. If that doesn't work run through the steps in the second box of the user tip.
All systems running Windows 7 as well as Malware bytes Premium latest version. Windows 7 updates are disabled but Microsoft defender was running either in background or fully enabled and sill updating. On or about 5/15/2024 either a Microsoft defender update (signature update) or a Malwerbytes update was installed. the result was upon shutdown or reboot command and consequent reboot. The following message is displayed:
This is a log grab from one of the affected systems attached. We have a system in our office with windows 7 and is running Malwarebytes Teams. It IS Not affected at this time and was just updated to the new yesterday to the newest teams version. We will send a log grab from that for you as well.
I work for a software company that has access to several customers still on Windows 7 and Server 2008. Every single one of these machines are doing this starting this past week. I found this thread on google. Only one customer has Malwarebytes. Seems like either an attack or a ticking time bomb in microsoft code. DISM and SFC wont fix it.
I know nothing about the Rust programming language, but could this error be related to Rust ending support for Win 7 and Win 8.x with the release of Rust v1.76 in Feb 2024? See the announcement in the Rust Windows Support Schedule 2024.
According to a 24-Mar-2024 post by Nadahar in How to make RustDesk builds work on Windows 7 (and probably Windows 8) any executable compiled with Rust v1.76 or higher will now throw the error "The procedure entry point ProcessPrng could not be located in the dynamic link library bcryptprimitives.dll" when it runs on machines with these older OSs.
I seriously do not believe it is related or has anything to do with it. Windows 7 did not ship with Rust and there was no link to download, update, or recommend Rust directly from Microsoft in the past that I recall.
I'm having the same issues on all my server 2008r2 servers. I found that the event ID for the alert is 26 and only happens when logging in/out or on reboots. I reboot 1 of the servers daily and was able to narrow down that the issue first appeared on 5/11. There were no windows updates installed on that date however I did update the screenconnect agent to 24.1.7.8892. I was able to confirm that the connectwise screenconnect agent is causing the problem by uninstalling the agent and reboot, issue goes away. If I reinstall the agent the problem comes back. I opened a ticket with connectwise and they said they are working on releasing a fix soon. As server 2008 and 2008r2 are affected I would bet win 7 machines are too. Hope this helps as it was driving me nuts as well.
c80f0f1006