I'm updating an R package that I last released (with no problems) on R3.6. I've since updated to R 4.0.0 and Rtools 40.
The package builds and runs successfully on 64-bit R. But I see that on win builder, the package's testthat tests fail on win32 (but not win64).
To diagnose the failure, I'm building the package on my 64-bit Windows 10 machine, using a 32-bit version of R and devtools::install(args= "--no-multiarch").
I've edited the PATH environment variable, replacing:
C:\Program Files\R\R-4.0.0\bin\x64 with C:\Program Files\R\R-4.0.0\bin\i386
C:\rtools40\mingw64\bin with C:\rtools40\mingw32\bin (and I've also tried C:\rtools40\clang32\bin)
The install process is indeed looking to mingw32 for the g++ and gcc executables. Installation is successful, with no warnings or errors.
However, when I attempt to load the package with devtools::load_all(), I see:
Error in inDL(x, as.logical(local), as.logical(now), ...) :
unable to load shared object 'C:/path/to/PACKAGENAME/src/PACKAGENAME.dll':
LoadLibrary failure: %1 is not a valid Win32 application.
If I instead run library('PACKAGENAME'), then run tests, the R GUI freezes and exits silently -- paralleling the failure on win builder.
I'm struggling to diagnose why a DLL that works perfectly on 64-bit won't work on a 32-bit architecture. The only substantive change I've made to the C++ code is to replace some ints with typedef int16_t xint.
The problem seems to have been the existence of 64-bit dlls in the package's source folder (as insinuated by the error message), created by 'devtools'.
Once these files were deleted load_all would happily re-create them using the 32-bit compilers.
Related
I'm writing a project in C++ with SDL2 on 64-bit Windows 10 using Visual Studio 2015. I recently purchased a new Windows 10 laptop and cloned my project from github. My project compiles correctly, but I get the following error when I run it:
The application was unable to start correctly (0xc000007b). Click OK to close the application.
Based on my research so far, this error is usually caused by loading an incompatible DLL, e.g. a 64-bit version instead of 32-bit. Suggestions I've found so far include:
Checking that I'm using the 32-bit versions of the SDL2 DLLs
Installing/reinstalling the x86 version of the Visual C++ Redistributable for Visual Studio 2015
Using Dependency Walker to troubleshoot which DLL is failing
My project is set to build for Win32, and I've ensured that I'm using the 32-bit versions of all DLLs I'm explicitly linking (libfreetype-6, libpng16-16, SDL2, SDL2_image, SDL2_mixer, and SDL2_ttf). I have confirmed that the x86 VC++ Redistributable is installed on my machine.
Finally, I've attempted to use Dependency Walker to determine what DLL might be causing the problem (although I've read caveats that Dependency Walker has a lot of false positives). These were the results:
Dependency Walker static analysis
Dependency Walker profiling results
After that point, the profiler freezes and never continues. Note that the SDL components and the VC runtime are loading without error.
The program compiles and loads correctly on my two older machines, one running 32-bit Windows 7 and one running 64-bit Windows 10.
Now for the actual question. What other steps can I take to debug this crash? Or does anyone see from the information I've provided what I'm doing wrong?
Related questions:
The application was unable to start correctly (0xc000007b)
Win 7, 64 bit, dll problems
Using SDL_image in Visual studio 2010, with error "application was unable to start correctly 0xc000007b"
Edit:
As rflobao suggested, I was using the 64-bit version of Dependency Walker on a 32-bit exe. Here is the new output of my profiling run:
At this point, as before, Dependency Walker freezes. I'm still totally lost and don't feel like I'm any closer to being able to determine what's causing the problem.
Note that Dependency Walker has 32 and 64 bit version. If your application is 32-bit you should use the 32 bit version. Otherwise the Dependency Walker will see the libs to System32 and not SisWOW64.
You image show 32bit and 64bit libs mixed, where 64 has error.
This is by no means completely reliable, but you can give it a try. It requires dumpbin.exe, which is included with Visual Studio.
First, get a list of dependent DLLs for your program, resolved against your path:
del dlls.txt
for /f %d in ('dumpbin /dependents Questless.exe ^| findstr /ic:".dll"') do #echo %~$PATH:d >> dlls.txt
Then get the bitness of each:
for /f "delims=" %d in (dlls.txt) do #echo %d & dumpbin /headers "%d" | findstr /c:"machine (x"
This will produce output like:
C:\Windows\System32\kernel32.dll
8664 machine (x64)
C:\programs\ed23\bin\hydra.dll
14C machine (x86)
Note that this is incorrectly using the kernel32.dll from System32, rather than the WOW6432 one, so it shows that as x64. That's because it just used the path, when the Windows loader will actually use the WOW6432 mapper, SxS, the application manifest, and only fall back on the path if none of those resolve the dependency. It also doesn't find dependents of dependents (you could script recursing through the dependents, but be sure to filter out duplicates), and of course doesn't know anything about run-time explicit dynamic loads.
Nevertheless, it's a quick way to get a short list to check, and might identify your problem.
I feel profoundly dumb, but I finally figured out the real problem. I'm using the SDL font library SDL2_ttf, and I simply hadn't copied zlib.dll from the SDL2_ttf lib directory into my build directory. I don't understand why the error message was so cryptic; in the past missing DLLs have given me a helpful "foo.dll is missing" error message.
Anyway, thank you all for your help. At least I've learned a useful lesson: always make sure all the required DLLs are present before suspecting a more complex problem.
i'm trying to create an installer for my opencv project. The Projects runs just fine, no error while compiling or at runtime.
And i need the program to run on other machines as well, so i thought of making an installer. I've read that MS VS 2013 has discontinued the Deployment tool and so i am using InstallShied Limited.
I'm setting everything according to their tutorial and i am adding the opencv libs, it builds and i can install my application. But as soon as install it on other machine i get the following errer message:
The procedure entry point _except1 could not be located in the dynamic link library opencv_imgproc.dll
I also get this error if i just copy the dll files to another machine along with the exe file. Does this mean, that the dlls are not compatible with the system? i am using windows 8.1 on both machines. and its also weird that it runs when i build it from VS.
Any advice is greatly appreciated.
regards,
hh
Solution: i had the 64bit dlls included and runnning on 32bit. The 32 Bit dlls are in vc10
Is there a way to tell the full path of every DLL used while compiling?
I am trying to make a DLL with easy-to-Marshal functions to communicate between a C# application and a filesystem Minifilter (currently using the Minispy sample to check if everything is running smoothly).
It was successfully compiling and running when using "Win32" as my target platform in Visual Studio 2013, but when printing out pointers with printf("%p",...); their length was only 8 characters where they should have been 16 (my computer is 64 bits) which threw off future pointer juggling.
My active solution platform has always been x64 for the other projects. Unfortunately, changing the platform in the Configuration Manager to x64 for the DLL generates the following error during compilation:
Error 1 error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
I checked online and this seems to be a configuration problem of some part of the solution, but all my projects should be compiling in x64. Cleaning and rebuilding to remove old files had no effect either.
I have used dumpbin.exe to check the Machine types of the DLLs I think my library is linking to and everything seems in order. I got these by checking the linker command line options in my project's Properties, but their names don't show where they are read from ( ex: kernel32.lib; user32.lib; gdi32.lib; fltLib.lib ... ). Since I'm still having this problem, I think it might be linking to the wrong (32bit) versions of the same DLLs.
Is there a way to tell the full path of every DLL used while compiling? Or better yet, is there a way to tell which DLL specifically is causing the LINK1112 error?
I have used the /VERBOSE:LIB command and removed the /NOLOGO option but the output is underwhelming, stopping right after the command to be executed with no other information.
I should have answered this when I solved it a couple months ago but I forgot I posted it here. But I'll try to recall what I did.
In the end, if I remember correctly, I'm pretty sure that what saved me was using Dependency Walker on the successfully compiled (x86) library. I used it before, but I was running it in the wrong mode (x64 or x86) and using the correct one revealed the missing modules for the x64 architecture.
I have a VC++ 6 application that is developed on old 32bit machines. The application is developed for 32bit machines, but can be run on 64bit machines - almost.
Some dialogs don't open.
Trying to debug - I have succesfully installed VC++ 6 onto a Windows 7 64bit machine. Upon compiling the project, the compiler says:
"fatal error RC1015: cannot open include file 'gxres.rc'."
What is gxres.rc?
Probably you don't installed all libraries that are used to build the project.
When I google for gxres.rc I find links on http://www.roguewave.com So you may have a library or parts of your code relay on other source code that isn't installed on the machine.
But you don't need to build on the target machine to debug the file. Just install VC6, place the source code and the exe with the PDB file on the machine an debug.
Also there may be still a chance to use the old remote debug features of VC6.
My last tipp: Don't use VC6 any longer... upgrade to a current version of VS!
I received the error "The application was unable to start correctly (0xc000007b)" after attempting to run my exe file of my C++ SFML 32-bit program I built in Visual Studio 2012. I statically linked the SFML dlls in my project, but incorporated the following dlls along with my program:
libsndfile-1.dll
openal32.dll
msvcp110.dll
msvcp110d.dll
msvcr110.dll
msvcr110d.dll
What is the problem?
The actual error code that you encountered is 0xC000007B. That is the NTSTATUS error code STATUS_INVALID_IMAGE_FORMAT. That error arises, almost invariably, because the application is 32 bit and attempted to load a 64 bit module, or vice versa. In your case, you state that your application is 32 bit, so it seems that it is attempting to link to a 64 bit DLL. Use a tool like Dependency Walker to diagnose the module which has the wrong bitness.
I don't understand why you are distributing both release and debug versions of the MSVC runtime. You only need one, and that one should be the release versions. The files that end d are the debug versions. You are not permitted to redistribute them.
Error code 0xC000007B can also result if you run an application that has erroneously been statically linked with a .lib file that is an import library corresponding to a .dll (as opposed to a .lib file that is a static library). If you want to know more about the differences between a static library and an import library, see Why are LIB files beasts of such a duplicitous nature?
I was also facing the same problem yesterday. Then I installed the Redistributable setup for VS i.e. vc_redist.x86 for 32-bit machine, after that application start running. You can use either 32-bits or 64-bits setup according your machine.
May it'll help you.
Thanks