I installed CUDA 5.0 and Arrayfire 1.9, and when I compile the example files, they work perfectly.
If I try to set up my own project in a different folder, I get a runtime error when I try to use anything related to the af namespace. I get the same error if I literally copy the hello-world example folder to another location and try to compile it from there. This indicates something, but I don't know what because I have little experience with using external libraries.
The error is:
"The application was unable to start correctly (0xc000007b). Click OK to close the application."
My debug output is:
CODE: SELECT ALL
'DerdePoging.exe': Loaded 'C:\Users\######\Dropbox\Public\2D_CUDA_UNWRAPPER\Unwrapper_ArrayFire\DerdePoging\Debug\DerdePoging.exe', Symbols loaded.
'DerdePoging.exe': Loaded 'C:\Windows\SysWOW64\ntdll.dll', Cannot find or open the PDB file
'DerdePoging.exe': Loaded 'C:\Windows\SysWOW64\kernel32.dll', Cannot find or open the PDB file
'DerdePoging.exe': Loaded 'C:\Windows\SysWOW64\KernelBase.dll', Cannot find or open the PDB file
The program '[5588] DerdePoging.exe: Native' has exited with code -1073741701 (0xc000007b).
I have noticed that my CUDA_LIB_PATH and CUDA_BIN_PATH and CUDA_INC_PATH variables are non-existent (even though I have created fully functional applications that use CUDA), so I created those (pointing to their respective folders in my Cuda installation directory). That didn't solve anything, didn't really expect it to.
Current environment variables:
AF_PATH=C:\Program Files\AccelerEyes\ArrayFire\1.9
CUDA_BIN_PATH=C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v5.0\bin
CUDA_LIB_PATH=C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v5.0\lib
CUDA_INC_PATH=C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v5.0\include
CUDA_PATH=C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v5.0\
CUDA_PATH_V5_0=C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v5.0\
Those first 3 could use a \, though nothing changed when I added these variables so I don't think it matters.
I think I am missing some crucial step when I create my VS2010 project. StackOverflow tells me it's probably a missing runtime .dll. So what's of key importance here is that the examples work fine, but in different locations, they don't. I think that narrows it down to some include path that is defined relative instead of absolute.
Not sure if it's relevant, but I'll post it here anyway:
using an NVIDIA geForce 540M with 1GB of memory. An Intel i5 2410M dualcore CPU. (Asus k53sv)
Thanks in advance.
Update:
following those exact steps gives the following error:
1>Release\main.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Update:
I'll try and get it to work in VS2010 Professional, which contains an x64 build configuration
Final Update:
Okay so if I had to explain this to my past self (so this post has some value to people who have the same error) I would say this:
-hardcode the include stuff, because the environment variables act weird
-push apply after every single configuration step in VS2010 (or they won't be saved)
-get VS2010 Pro so you can choose the x64 platform (this is critical and probably caused the first error, 2012 does NOT work properly)
You're right about CUDA_LIB_PATH and CUDA_INC_PATH being irrelevant (since CUDA 5.0). AccelerEyes has updated more recent builds of the ArrayFire library, but if you have an older release, then you're Visual Studio projects are probably still relying on the old (CUDA_X_PATH) paths instead of the new ones. Since the examples run fine, I think your problem is just that you haven't specified all the dependencies in your Visual Studio project...
First I suggest making sure that the ArrayFire .dll is in your system path:
Set environment variable PATH="%PATH%;%AF_PATH%\lib64" (assuming you are on a 64 bit machine. This allows your runtime to find the ArrayFire dll.
Now to fix the Visual Studio build:
Open up Project Properties
Under "C/C++" under "General" make sure that "Additional Include Directories" contains "%CUDA_PATH%\include" and "%AF_PATH%\include"
Under "Linker" under "General" make sure that "Additional Library Directories" contains "%CUDA_PATH%\lib\x64" and "%AF_PATH%\lib64"
Under "Linker" under "Input" also make sure that "Additional Dependencies" contains "libaf.lib" and possibly "libafGFX.lib"
Related
I have a winforms .net4.5.2 application which depends on a c++\cli wrapper which is included in the VS project by reference. When the winforms application, that is built using Any CPU, is launched a assembly resolver is used to point out the correct platform dll for the reference and Assembly.Load(ed) in the platform specific folders in the root of the application folder i.e. \x64 or \x86.
This c++\cli is now built using the v140 platform toolset which depends on the Universal CRT dll:s. Looking here https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/ I was able to locate the necessary dll:s (41 * 2 of them) and I did what I was told to copy them inside the \x86 and \x64 folders. Now since the change to v140 platform my application does not start anymore and ProcessMonitor file operations tell me the following:
SUCCESS C:\MyApp\x64\TheCLIWrapper.x64.dll
SUCCESS C:\MyApp\x64\ADependency.dll
SUCCESS C:\MyApp\x64\msvcp140.dll
SUCCESS C:\MyApp\x64\vcruntime140.dll
SUCCESS C:\MyApp\x64\api-ms-win-crt-runtime-l1-1-0.dll
NAME NOT FOUND C:\MyApp\ucrtbase.dll
How is this even possible if before assembly resolving my c++\cli wrapper I explicitly set the dll directory (using SetDllDirectory) to the C:\MyApp\x64 folder? By this I mean why is the loading process looking in C:\MyApp for the ucrtbase.dll?
Naturally, if all the 41 dlls of a specific platform are copied to the root C:\MyApp\ folder it works but this is not an option for me, nor is the installation of c++ runtime executable on the clients running the application.
Does anyone have an idea or any tips on how to solve this deployment problem?
So you basically wanna do x-xopy deployment with x86-dll's in MyApp\x86, and x64-dll's in MyApp\x64?
How about explicitly loading the dll's with LoadLibrary?
I used procmon to inspect where the UCRT DLLs were trying to load each other from. Noticed the paths it was searching did not include the path set from the earlier SetDllDirectory. No matter what I tried the paths it searched seemed to only include the default values.
The working directory was always included as per Dynamic-Link Library Search Order and the only solution I could get was to change the current working directory to the appropriate one, load the DLL with the UCRT requirement, and change it back. Nothing else worked (including changing PATH environment variable)
Note this is very much not threadsafe
I was running a unit-test in Visual Studio today using FakeItEasy. I was offline and found the following symbol-loading to be happening and taking a long time:
My question is, where does the path Z:\Builds\work\... come from and why is Visual Studio trying to load symbols from that path. Could it be that this path corresponds to the CI that the binaries were built on? If so, is it a thing that the maintainer of the library should fix, or something that I must locally configure? I am using the FakeItEasy 1.25.2 binaries that I fetched via NuGet.
I am aware of the fact that you can disable symbol loading (e.g. see this question), but actually I want the symbols to be loaded if possible.
Yes, Z:\Builds\work\… is the path from which TeamCity builds FakeItEasy.
I'm not a big symbol user, so am not sure what you want "fixed". Why are you loading the symbols, and what behaviour would you expect in this case?
If we push the symbols to SymbolSource.org you'd still need to be online to access them, no?
Can you give an example of a NuGet package that behaves how you'd like?
How does it behave in your situation?
PDBs can be built for debug configuration and release configuration and it's typically a good idea to keep them for debugging purposes. FakeItEasy or any other DLL or EXE, contains the full path to the PDB file where it was located during compile time. If that path is part in a DLL (or EXE), Visual Studio will try to load symbols from there.
To see that information, get DebugDir and run debugdir <path to>\FakeItEasy.dll. Or, in any hex editor, search for pdb.
You'll find the full path of the PDB along with some other information. Since it wasn't you who built the DLL, the PDB is not present on your disk and you'd need to download it from a symbol server.
The Sourforge clone of DebugDir contains supports a command line parameter clean which can remove debug information. If you want to get rid of Visual Studio accessing the non-existing Z: drive, you can remove the path to the PDB file.
I'm writing a 32-bit C++ application on Windows 8.1 x64 using Visual Studio 2013 that depends on Python 3.3 and libVLC. I have python33.dll, libvlc.dll, and libvlccore.dll in the same directory as my executable, which I also have set as the working directory under Project > Properties > Debugging. According to MSDN, unless you're using the altered search path (which should only apply if you're using LoadLibraryEx to load the DLLs at run-time; in my case these DLLs are loaded at load-time), the application directory should always be searched before the system directory. However, according to Visual Studio, all three of these DLLs are being loaded from C:\Windows\SysWOW64. This is causing me problems as the version of libVLC I have there is much older than the one I'm trying to use.
That MSDN article only lists 3 exceptions to the normal search process. These DLLs are loaded as soon as the process starts, so obviously it couldn't be the system versions were already loaded (but just to be sure, I created a .local file since it mentioned redirection would override that, and it had no effect). I've checked the registry to see that they didn't somehow get registered as "Known DLLs", so that doesn't appear to be the problem. It's possible that python33 is being loaded as a dependency of Boost.Python, but even if it's loaded only by name the app directory should still be searched first, and in any case none of my other dependencies reference VLC. As a guess I tried marking the VLC libs as delay-load (I couldn't with Python due to data imports), and I got the following warnings, which I found interesting:
1>LINK : warning LNK4199: /DELAYLOAD:libvlc.dll ignored; no imports found from libvlc.dll
1>LINK : warning LNK4199: /DELAYLOAD:libvlccore.dll ignored; no imports found from libvlccore.dll
However, dumpbin shows that my compiled exe imports several functions from libvlc.dll.
I could of course replace or delete the system versions, but that's not really a solution if I ever attempt to distribute this application. I'm not really sure what else would be causing this. Can anyone suggest anywhere else for me to look?
We have a large project, recently we've merged two dll into one for some reason. Then we got an Error LNK1318 while linking, and mspdbsrv.exe reached 4063MB of max memory usage,then linker report Fatal Error LNK1318 Unexpected PDB Error, OK(0)
mspdbsrv.exe is the utility program that is launched behind the scenes to create PDB symbols used for debugging your code.
I've read anecdotal reports regarding earlier versions of Visual Studio (e.g., 2005) that this little process has been a source of pain for before in the past, but I haven't run into any with daily dev work in 2010.
It sounds to me like you've built up a cache of PDB files that it's trying to combine into one at build time. Only problem is, that produces a file that's 4 GB (!!) in size. I'd delete all of the temporary files associated with your project and kill the mspdbsrv.exe process (or restart the computer), and then try building again. You might also want to turn off incremental builds, which rebuild only the information that has changed since the last build. That'll force a full rebuild, which should produce a PDB file without any extra bloat.
I have an executable (compiled by someone else) that is hitting an assertion near my code. I work on the code in Visual C++ 2003, but I don't have a project file for this particular executable (the code is used to build many different tools). Is it possible to launch the binary in Visual C++'s debugger and just tell it where the sources are? I've done this before in GDB, so I know it ought to be possible.
Without the PDB symbols for that application you're going to have a tough time making heads or tails of what is going on and where. I think any source code information is going to be only in that PDB file that was created when whoever built that application.
This is assuming that the PDB file was EVER created for this application - which is not the default configuration for release mode VC++ projects I think. Since you're asserting, I guessing this is a debug configuration?
Short of any other answers, I would try attaching to the executable process in Visual Studio, setting a break point in your code and when you step into the process you don't have source to, it should ask for a source file.
Yes, it's possible. Just set up an empty project and specify the desired .exe file as debug target. I don't remember exactly how, but I know it's doable, because I used to set winamp.exe as debug target when I developed plug-ins for Winamp.
Since you don't have the source file it will only show the assembly code, but that might still be useful as you can also inspect memory, registers, etc.
Update
If you are debugging an assertion in your own program you should be able to see the source just fine, since the path to the source file is stored in the executable when you compile it with debug information.