My automated script for starting and stopping VMWare Server virtual machines has stopped working. vmware-cmd has started raising the error:
The ordinal 3288 could not be located in the dynamic link library LIBEAY32.dll.
I am not aware of any specific change or update when this started happening.
I have found a bunch of other people reporting this problem (or very similar) but no solution.
Do you know what caused this error, and/or how to fix this?
I would have said that something must have updated either the LIBEAY32.dll or another dll that depends on it. You may find some helpful information using the depends tool. If you use this to open up the perl.exe then it should highlight the dependency path that produces the problem. You can compare this with other machines on which perl runs.
The ordinal is effectively a function that is expected by perl or a dll, but is not present in the verision of LIBEAY32.dll that you have. The depends tool makes this quite clear.
Have discovered that this only occurs when the script is run on a different drive to the one where the EXE is located. As a work around for this I have simply moved the scripts execution.
Apparently the DLL relates to SSL, which isn't relevant to what I'm doing, so this is a suitable workaround. I'm guessing that the problem is caused by changes in the EXE for how it determines relative paths (unlikley as nothing (AFAICT) has changed). Or the %PATH% environmental variable has changed (more likely).
Hope this helps someone in the future.
Please check your path settings and see if you have included "C:\Program Files\VMware\VMware Workstation" for VMWare management purpose. Once you delete it, you won't see the error no more.
Related
I have recently started using r markdown and I am having issues with installing pandoc-crossref in window.
I have tried approaching friends on getting the set-up but to no avail. I have tried searching on the web but couldn't find anything useful. I tried following the directions here text to no avail. I will be grateful if anyone knows where i can get the set up and how to go about installing it.
You don't give any information about what errors you receive, so it is hard to provide useful help. This being said...
Trying to guess what your problem is. It is likely that you are getting the error could not find executable pandoc-crossref when trying to compile. Assuming that that is the case, your problem might be the following. Notice that pandoc-crossref.exe is not an installer, but an executable, so double clicking on it in an attempt to install it will do nothing except bring up a terminal for an instant. Is that what you have done? Where did you place it?
Leaving pandoc-crossref.exe e.g. in your downloads folder or on your Desktop would give the could not find executable pandoc-crossref error when trying to compile, because the executable needs to be in your $PATH, or pandoc will not be able to find it and run it.
A possible solution. If my guesses above are correct, you might be able to solve your problem by placing pandoc-crossref.exe inside your pandoc program folder, where your pandoc.exe file is, which is by default in:
C:\Program Files\Pandoc\
So try to place pandoc-crossref.exe in that folder and see if it works.
If this does not help. Say exactly what it is that you tried to do, what errors you encountered, and maybe include a screenshot.
Recently I obtained a solution which has been created on another person's machine. I have been banging my head into the monitor in the past 2 days trying to fully migrate the solution to my machine. I have been manually changing the directory addresses of the solution and have not been able to compile the solution although I think I have corrected more than 100 paths as of now. Here's my first attempts to migrate the solution to my machine and resolve the issue of not being able to open any of the files.
Now I can open all the files in each project on my machine (after manually changing their paths). However, I am still getting the same errors and I'm not able to compile the project. Below is a picture of the errors I'm getting:
And here's the output log when trying to compile the project. So I wonder, can someone give me some advise on how I should go about doing the whole process automatically? In the output log I see there is a F:\Virtual ... path which indicates the solution been created on a virtual machine. However, I am not using a virtual machine and am not able to find the file file containing that path (F:...) so that I can change it to the correct one (I even do not know what the correct one should be since I am not using a VM).
If you are not able to help me through the description I gave or the output log file, you can download the whole solution from here and then give me some instructions on how I should go about compiling and using it. I really appreciate your help.
Chances are that someone went rogue on the project file, because normally all paths are defined in a way that is relative to the project or solution, making them portable.
In order to fix this, I see two options, either set up the project files from scratch or keep on hacking on them until they compile. Whichever path you take, keep in mind that VS supports placeholders like $(SolutionDir) you can refer to when setting up paths. If that doesn't work, please try to extract a minimal example.
Also, make sure you have a version control system set up, so you can retrace your steps. This should be standard in any software development, but considering the state of the project I wouldn't be surprised to find other, hairy places there.
I'm having an issue with regards to registering a *.dll under Windows 7 x64.
I've tried placing the *.dll in both, C:/Windows/System32 and C:/Windows/SysWOW64 and attempting to register with "regsvr32 xxxxx.dll" under an elevated command prompt. I also tried to register it from a seperate directory. It responds with the following error:
The module "xxxxx.dll" failed to load.
Make sure the binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files.
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.
The EventLog notes:
Activation context generation failed for "C:\(path-to-dll)
Dependent Assembly
Microsoft.VC90.ATL,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found.
Please use sxstrace.exe for detailed diagnosis
N.B. I have installed both x86 and x64 Microsoft Visual C++ 2010 Redistributables.
An interesting aside is that I attempted to register the same *.dll on my work x64 Windows 7 laptop and it registered as expected. I guess this leans towards the fact that some kind of C++ dependency is missing / ATL related?
If anyone could help point me in the right direction or shed any additional light on the matter; i'd be more than grateful.
Regards.
This is almost certainly due to a missing dependency. Use a tool like Dependency Walker to find the required dependencies of the DLL. Or, if the DLL is supplied by a third party, read their documentation which should specify the required dependencies.
Note that Microsoft.VC90.ATL indicates version 9 of MSVC which is VS2008. So you would need to install the MSVC 2008 runtime to meet that dependency. It looks like you installed the MSVC 2010 runtime by mistake.
Finally, please don't put files into the system directory. It belongs to the system and should not be modified by you.
Dependent Assembly
Microsoft.VC90.ATL,processorArchitecture="x86"
This indicates missing Visual C++ runtime module (see Visual C++ Libraries as Shared Side-by-Side Assemblies). It is available as redistributable installer (this is presumably the one you need; x86 variant), which you need to install before registering your DLL (which is in turn dependent on missing component).
There is also another reason why this fails. I just ran into this myself. I was using API methods that did not support Windows 7, such as PathCchRemoveFileSpec which I had to update to the older, deprecated PathRemoveFileSpec. I used Dependency Walker to verify this was the cause. Dependency Walker lies a bit. If you look at my screenshot (below), the red section shows the actual problem - the methods it wasn't able to resolve in DLLs it has, etc. - but the blue shows DLLs that are actually not the problem at all (these DLLs exist). Since Dependency Walker is so old, it lies a bit (its outdated, it thinks something isn't available from time to time), but usually, it also tells the truth...you just have to scroll down a bit from the top left pane like I did. Note to self: please scroll down next time. Anyways, once I ditched pathcch.h, everything worked on 7. Happy coding.
I got relieved from this error message. In my binary path, I had a SPACE. Just replaced the SPACE with UNDERSCORE(_). It worked for me.
as i have also faced the same issue while registering the x.dll through Regsvr32,there is one of the possible reason is that x.dll might be unmaged dll.
To use unmanged dll export function in the dot net code, you have to use Dllimport.
I guess everyone has run into missing dll's issues from time to time. What I am trying to get is the 'recommended' method to find and install the dll's. Finding out which dll's are missing is easy enough using depends.exe.
Don't use depends.exe anymore, it hasn't kept up with developments in the Windows core and deployment strategies like the side-by-side cache. Trying to fix the warnings it gives will actually mess up your machine pretty badly. Only use it for hints if a program actually fails to start.
99% of the missing dll errors that I tend to come across are missing C++ runtime libraries (eg =MSVC*.dll=) or the .Net framework, where the developer has built with dynamic linking to the C++ runtimes but hasn't created an installer with the required merge modules, or they have built a debug version which links against the debug runtime libraries which you are not permitted to redistribute.
In the vast majority of these cases, simply installing the correct Visual Studio 2005/2008 C++ runtimes (eg see here) or .Net framework will fix the problem.
That depends greatly on which DLLs are missing and why they are missing, I don't know that there is a one-size-fits-all answer.
My advice would be to use depends to find which DLLs are missing, try to find out where those DLLs were supposed to be installed (and what application was supposed to install them), and then try to reinstall that application or find out what happened to screw up the dlls.
Another thing to check is for 32bit/64bit mismatches, that can make it seem like DLLs are missing sometimes, especially on 64bit platforms.
Or if you are using .NET, you can have trouble with assembly versions and the GAC sometimes.
You can also check the PATH environment variable, I would advise against blindly adding to your PATH to get it to find DLLs you want, that can cause all sorts of other weird problems.
Sometimes you have to hack around with the PATH or copy files to get things to work, but it is usually better if you can figure out what went wrong in the first place and fix it.
Get the DLL from its publisher's website, if possible, and then follow the publisher instructions to install. Don't forget to respect licensing rules!
alt text http://img63.imageshack.us/img63/5726/screenshot20100125at124.png
I keep getting multiple error windows for an app i'm developing asking for ._libpal_bullet.dll when it should really be just libpal_bullet.dll. The weird thing is after I get all the error messages, the app runs anyway using the correct dlls that exist in the same directory.
How can i get rid of these errors?
You can use Dependencies Walker to step through the code to see who is invoking the call to the DLL. Maybe you have the ._libpal_bullet.dll included in your release configuration.
Thanks Extrakun, you indirectly helped me figure this one out.
I guess this happens when you copy code between OSes.
The problem was that there were duplicate files of these library names in the build folder. They were metadata files from OS X, which must have come over to the Windows side when I copied the folder to Windows. It's strange that they would be attempted to be executed even though they have different names to the proper DLLs.
Anyway deleting the files (they were hidden!) solved the issue.