View Full Version : 0xc000007b error on win7 64bit VM
MonoS
16th February 2015, 19:48
As the title says i get 0xc000007b error when i try to execute VS on a VM with windows 7 64bit [2x Xeon E5-3420@1.9GHz/ 16GB of ram].
I've installed first python 3.4.3RC1 then vs r26 [before i had installed vs 32bit cause QTGMC, uninstalled it with python before installing the 64bit version].
What can cause this problem??
LoRd_MuldeR
17th February 2015, 01:29
0xC000007 is the NT status code for STATUS_INVALID_IMAGE_FORMAT.
This error could mean that you are trying to run 64-Bit code on a 32-Bit OS. Or that you are trying to load a 64-Bit DLL into a 32-Bit process (or vice versa).
Do I get you right that "windows 7 64bit" is the guest OS, running inside the VM where the problem occurs?
If so, the former problem can be excluded. In that case I would suspect there is some "32-Bit vs. 64-Bit" DLL issue with your VapourSynth/Python installation or with one of the plug-in's in use.
MonoS
17th February 2015, 12:08
Yes is the guest os, IIRC is a bare metal VM
Tried again with a clean install: uninstalled vs and py, then ccleaner and then reinstalled py and vs, but still nothing.
Maybe it's an hint, but i get the same problem with vapoursynth editor even if i don't have vs/py installed
the_weirdo
17th February 2015, 12:56
Try to re-install MSVC++ 2013 runtime (x86 (http://go.microsoft.com/?linkid=9832156), x64 (http://go.microsoft.com/?linkid=9832146) [in this case you need the later, but it doesn't hurt to install the former too, in case you have 32-bit applications which need it]). And just remember that you shoudn't download random DLL files from the Net and put them to system folders.
Myrsloik
17th February 2015, 13:38
Try to re-install MSVC++ 2013 runtime (x86 (http://go.microsoft.com/?linkid=9832156), x64 (http://go.microsoft.com/?linkid=9832146) [in this case you need the later, but it doesn't hurt to install the former too, in case you have 32-bit applications which need it]). And just remember that you shoudn't download random DLL files from the Net and put them to system folders.
Not needed. They're installed by the vapoursynth installer.
the_weirdo
17th February 2015, 14:59
They're installed by the vapoursynth installer.
But it seems that the VS installer won't overwrite those run-time libraries if they already exist. Redist packages from MS can repair them.
LoRd_MuldeR
17th February 2015, 15:54
Maybe it's an hint, but i get the same problem with vapoursynth editor even if i don't have vs/py installed
Is VapourSynth Editor written entirely in Python or does it use "native" code?
In the latter case, it must match the "bitness" (32-Bit vs 64-Bit) of your VapourSynth/Python installation, because otherwise it wouldn't be able to load/use the required DLL's.
In the former case, you should at least double-check that it runs in the same Python environment where VapourSynth has been installed.
Anyway, you may want to try to identify the conflicting module with Dependency Walker (http://www.dependencywalker.com/). You need to use the "profiling" feature to see what's going on at runtime.
MonoS
17th February 2015, 17:42
I used Depencency walker on both vs editor and vspipe and get the same error when loading this library: MSVCR120.DLL [the only one at 32bit in the dependency list], so it's msvc the problem [but it's strange because i've installed it before when the_weirdo told me to do it].
Then i've unistalled all redist of msvc and reinstalled only 2013 ver.
Now it works, but why it doesn't worked from the beginning??
Myrsloik said that vs installer would install such library, then why it was outdated??
Thanks you all for the help :D
LoRd_MuldeR
17th February 2015, 17:49
Now it works, but why it doesn't worked from the beginning??
Myrsloik said that vs installer would install such library, then why it was outdated??
Visual C++ Runtime DLL's can be installed system-wide, which is what the Visual C++ Redistributable installer does. Using this method, the 32-Bit and 64-Bit versions of the CRT can be installed "side by side" - and each application should pick the proper CRT DLL from either 32-Bit or 64-Bit system directory. Also, the redistributable installer is supposed to be "smart" enough to only install the CRT DLL's, if they haven't been installed already.
However, starting with VS2010, you can also put a "private" copy of the Visual C++ Runtime DLL's directly into the directory where the program file is located. In this case, the program will just ignore the system-wide CRT DLL's (if available) and simply load whatever it finds in its local directory. Thus, if you put the wrong version – 32-Bit CRT DLL for 64-Bit program file, or vice-versa – into the program directory, you will have a problem!
MonoS
17th February 2015, 17:54
However, starting with VS2010, you can also put a "private" copy of the Visual C++ Runtime DLL's directly into the directory where the program file is located. In this case, the program will ignore the system-wide system-wide CRT DLL's and just load what it finds in its directory. Thus, if you put the wrong version (32-Bit CRT DLL for 64-Bit program file, or vice-versa), you will have a problem!
Vs and VSEditor folder where pristine when i tried, so is impossible that they had some old 32bit crt dll, maybe those system wide were outdated, but why??
LoRd_MuldeR
17th February 2015, 17:58
Vs and VSEditor folder where pristine when i tried, so is impossible that they had some old 32bit crt dll, maybe those system wide were outdated, but why??
Possibly wrong CRT DLL included with VSEditor? :confused:
Also possible that, for whatever reason, your system-wide CRT DLL's had been messed up. But the Visual C++ Redistributable installer, included with VapourSynth, didn't fix this, because it only detected that the CRT "is already installed".
That would explain why manually forcing a clean re-install of the CRT has fixed it for you...
MonoS
17th February 2015, 18:02
Possibly wrong CRT DLL included with VSEditor? :confused:
Also possible that, for whatever reason, your system-wide CRT DLL's had been messed up. But the Visual C++ Redistributable installer, included with VapourSynth, didn't fix this, because it only detected that the CRT "is already installed".
That would explain why manually forcing a clean re-install of the CRT has fixed it for you...
i don't think so, i've recently installed vs64 on my personal pc and had no trouble whatsoever.
Maybe in the vm there was configured the default user as a non administrator??
the_weirdo
18th February 2015, 04:00
Possibly wrong CRT DLL included with VSEditor? :confused:
VapourSynthEditor doesn't include CRT DLL in its packages, maybe because they're supposed to be installed with VapourSynth.
Maybe this is not the case here, but some (or many?) people have a habit that if they see a "missing DLL" dialog, they'll go search for that DLL file on the Internet, download it and put it to System32 (must be System32) directory. And it's often the cause of this problem.
Mystery Keeper
18th February 2015, 13:20
Is VapourSynth Editor written entirely in Python or does it use "native" code?
VapourSynth Editor is written entirely in Qt 5, so it is 100% native. Yes, I supply MSVS 2013 build without runtimes, so users need to install them manually. I'll probably switch to supplying MinGW builds, since GCC 4.9.2 seems to produce faster code than MSVC 2013. Those will come with GCC runtimes.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.