I am trying to run CUDA in emulation mode in Visual Studio 2008.
It is showing this problem at runtime:
cudaSafeCall() Runtime API error in file <xyz>, line abc : feature is not implemented
for example in one case it turned out to be this one:
cutilSafeCall(cudaGLRegisterBufferObject(pbo));
and if I commented this one out then:
cutilSafeCall( cudaMalloc((void **)&dev_triangle_p, triangle_size));
Is this because I am running the code in emulation mode? Any other suggestions?
Seems like the most probable reason for this is a mismatch between libraries. For example you're building against the debug library cudartD.dll but loading the release version. Alternatively you could be using another library which was built in release and now loaded against your project which is build for debug, the CUDA utils library cutil which comes with the samples is an obvious candidate.
Without more details it's hard to say anything further.
Related
I'm working on a plugin for Autodesk 3ds Max 2017. As per Max's documentation, the plugin is compiled inside VS 2017 using the VS 2015 toolset against the 10.0.10586.0 Windows SDK.
When the plugin is loaded by 3ds Max, it in turn programmatically loads a number of DLLs using LoadLibrary(). Until recently, that was working fine on my machine. It's also still working fine on other developers' machines.
What happens now on my machine is that LoadLibrary() fails and returns a null handle. The error code is 127, i.e. "The specified procedure could not be found."
I am quite sure that DLLs that the one I'm trying to load to depends on are available on the system. I have triple-checked with both Dependency Walker and its modern incarnation, Dependencies.
In fact, the following program run inside Visual Studio 2017 (also using VS 2015 toolset against the 10.0.10586.0 Windows SDK) is able to load that DLL just fine:
#include <Windows.h>
int main(int argc, char* argv[])
{
auto result = LoadLibrary(L"C:\\path\\to\\appleseed.dll");
}
To investigate this problem further, I've turned to GFlags which is part of the Debugging Tools for Windows 10.
Here is the full debugger output emitted when calling LoadLibrary(): https://gist.github.com/dictoon/b3f9f7cb52d2d81078965133d5035a03
I believe (but I'm not 100% sure) that the relevant error from this output is the following:
5f4c:54bc # 131346281 - LdrpReportError - ERROR: Locating export "StackWalkEx" for DLL "C:\Windows\SYSTEM32\dbgeng.dll" failed with status: 0xc0000139.
Exception thrown at 0x00007FFCC6A9EAA8 (ntdll.dll) in 3dsmax.exe: 0xC0000139: Entry Point Not Found.
5f4c:54bc # 131346281 - LdrpGenericExceptionFilter - ERROR: Function LdrpSnapModule raised exception 0xc0000139
Exception record: .exr 000000000223F030
Context record: .cxr 000000000223EB40
dbgeng.dll appears to be Visual Studio's debugger so I thought that maybe the error would only occur when 3ds Max was run inside Visual Studio with the debugger attached but that's not the case: the DLL also fails to load when 3ds Max is launched on its own.
Inspecting C:\Windows\SYSTEM32\dbgeng.dll with Dependencies reveals that it does export a StackWalkEx() symbol:
Edit 1: #RbMm commented that StackWalkEx() is actually not exported by dbgeng.dll but by dbghelp.dll as the screenshot below shows:
Edit 2: With a release build of the DLL I'm trying to load, everything works fine too. Looking at the debugger's output, no attempt is made at loading dbgeng.dll or finding StackWalkEx().
Edit 3: It appears that the debug version of the library I'm trying to load does have a dependency toward dbgeng.dll:
But a small test DLL written from scratch doesn't!
Edit 4: I now suspect that Boost 1.69 (on which the DLL I'm trying to load depends) to which we recently switched (from Boost 1.55) has introduced a dependency on dbgeng.dll via its Stacktrace library introduced in Boost 1.65.
The problem is an older version of dbghelp.dll which ships with 3ds Max and conflicts with the newer version the appleseed.dll has been linked with during the debug build.
The call to the function StackWalkEx, which failed, has a dependency on dbghelp.dll
StackWalkEx function
The solution is to inactivate or replace the older, incompatible version of dbghelp.dll inside the Max root directory.
StackWalkEx is part of DbgHelp and used by System Services. It may have been updated recently during a Windows update causing the breaking change.
It's my first time using Visual Studio 2017. I built a simple program in C++ on my PC. I was curious to see if my program works on another PC. I tried to execute the .exe on the other computer and it gave me this kind of error:
vs(some letters and numbers).dll is missing.
I assume that the .dll in question is part of Visual Studio.
I tried on a third PC, and this time the cmd stops working and becomes unresponsive after I execute my .exe.
I also have this problem when I compile with MinGW using the g++ compile feature in the cmd. When I execute the program compiled with MinGW on another PC, it gives me the same error, but this time it says something like
gw...dll is missing
Is there a way to avoid this error without installing the Visual Studio (or MinGW at this point) on any other PC I want my program to run on?
If you're interested in the code, I can put it here, but I don't think it's the problem here because I have the same issue for every other .exe compiled on my PC.
Here's a picture of the error:
In case of Visual Studio, you need to install Visual C++ Redistributable libraries or provide the libraries that are required by your application with .exe file (I am not sure if it violates license or not though).
In case of MinGW, you need to provide required DLL as well. I guess that you need libgcc_s_dw2-1.dll and libstdc++-6.dll, but you would better check it yourself. And remember about the license.
You may use Dependency Walker to analyse dependencies of your application.
UPDATE (2017-12-12):
I've missed the time you posted the screenshot. As far as I see from it the problem is that you are trying to run debug version of your executable: ucrtbased.dll is the debug version of the ucrtbase library and is only available (from what I know) from Visual Studio distribution. If you want to run your application on the computers that do not have installed Visual Studio, then you should use the Release version of your application.
In order to understand your problem you need to understand the concept of DLL.
Dynamic-link library(DLL) - As described by Microsoft:
A DLL is a library that contains code and data that can be used by
more than one program at the same time. For example, in Windows
operating systems, the Comdlg32 DLL performs common dialog box related
functions. Therefore, each program can use the functionality that is
contained in this DLL to implement an Open dialog box. This helps
promote code reuse and efficient memory usage.
So to put it simply, DLL is basically a bunch of compiled code, which is being linked to your code at load (or even run-time). Now, of course if your system is missing the DLL, your progrem will fail to work. To make things even worse, DLL are sensitive to the compiler that was used. So each DLL might have multiple version, so you will need to right DLL.
Now to the problem itself, the error message are the best way to start. They guide you what DLL are missing, and what is their name. For instance in your case "vs*.dll" is most likely related to Visual C++ runtime redistributable.
Finally, please note you have another consideration to make in addition to make your own system work: Every one that will use your code might face the exact same problem. So if you actually intend to share your .EXE with other people, you will need to understand how to guide them, or even automate their installation process.
I'm using Visual Studio 2015, and trying to compile a C++ code in Release mode, x86. My operating system is Windows 10, 64-bit OS and x64-based processor.
After it builds, if I run the .exe file from my laptop, it works perfectly fine. However, if I transfer everything in the Release folder to another computer (Windows 8) - no Visual Studio - along with two DLL files (pthreadVC2.dll and ucrtbased.dll), it gives me error 0xc000007b: the application was unable to start.
I've tried statically linking the libraries, but that didn't help. If I run the Dependency Walker, it says that the file - on my computer - has errors, and gives a log of what's wrong, which I cannot understand:
Error: At least one module has an unresolved import due to a missing
export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
I looked around on this website, and apparently it means that 64-bit DLLs are being loaded and I should change that from Path. How do I do that? And why doesn't it work on the other computer, which has the same processor? I installed the Visual C++ Redistributable for Visual Studio 2015, but that did nothing.
Another question: The code uses many external headers. Do I have to export them to the other machine as well? Aren't they compiled as a LIB File?
I'm sorry if I sound clueless, but I rarely write applications using Visual Studio. Thanks for your help!
That error code is an NTSTATUS code, specifically STATUS_INVALID_IMAGE_FORMAT. That usually means that the loader is finding 64 bit modules rather than 32 bit modules. Exactly which modules are the wrong bitness is hard for us to tell. Running the startup under Dependency Walker's profile mode would reveal all.
You do really need to get a clear handle on what dependencies your program has. You have specific dependencies related to your program that go beyond the normal MSVC runtime dependency. Only you can know what your dependencies are. A tool like Dependency Walker can help you understand them, but make sure your understanding is solid. Try not to use trial and error to resolve this.
I have a simple application which reads a few text files does some calculations and writes a few text files. Works perfect on my development machine (Server2008R2 VC++ 2010). I can't get it to run on a Win7 machine even thought I have installed/run the vs2010 redistribute x86.
The first error I got was missing mfc100ud.dll (yes, I'm using debug, if I try the release it just crashes, as debug tells you what's wrong). I put mfc100ud.dll in the application's directory, now fgets asserts as shown below. str is not null and the file did open successfully.
What have I missed?
My goal here is to just run the MFC app on the Win7 machine without have to install vs2010.
Another consideration, the only reason I am using MFC is for the COleTimeDate functionality. I've looked for alternatives but haven' found anything workable or as simple to use.
Thanks.
Assertion Error
This error occures if the file stream pointer (provided by fopen) is NULL.
Is it possible that you don't have any error checking after you used fopen?
Basically use "static linking" to the MFC and CRT. Than there is no Need to install and copy any runtime files.
Redistributable assemblies are only available for release builds. If you really want to distribute a debug build, you have two options:
link your app statically, so you don't need any shared DLL (such as mfc100ud.dll)
distribute together with your app (in your app folder) all the dependent DLLs. you can check the dependencies with depends.exe
I am running a Qt C++ Project in Visual Studio 2008 and I got this error message:
"The program can't start because QtCored.dll is missing from your computer. Try installing the program to fix this problem".
Then I copy: QtCored4.dll from C:\Qt\4.8.0\bin to the exe program
I run it again, I got:
"The program can't start because QtGuid4.dll is missing from your computer. Try installing the program to fix this problem".
Then I copy: QtGuid4.dll from C:\Qt\4.8.0\bin to the exe program
Then I run it again, I got:
"the application was unable to start correctly (0xc015002). Click OK to close the program.
Then I check the Event Viewer, I see this:
Activation context generation failed for "D:\rest\rrpT.exe". Dependent
Assembly
Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762"
could not be found. Please use sxstrace.exe for detailed diagnosis.
First of all, it is very strange to me because I am building and debugging the application on VS2008 but it asks for the dll files form VS2005. Then I copied those files from VS2005:
msvcm80d.dll - msvcp80d.dll - msvcr80d.dll
to the program folder but it is still the same error :(
And I think there is also something interesting:
Activation context generation failed for "C:\Bin\QtSolutions_PropertyBrowser-2.5d.dll". Dependent Assembly Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762" could not be found. Please use sxstrace.exe for detailed diagnosis.
why is that PropertyBrowser is dependent on VS2005?
Any idea?
It sounds like your copy of Qt was compiled with VS2005, thus it probably has a dependency on the version 8 runtime DLLs. But your application is built with VS2008 and thus has a dependency on the version 9 runtime DLLs. In general, you can't get both versions of the runtime DLLs into one process. VC++ tends to break binary compatibility between major versions.
You need to recompile your own copies of the Qt DLLs with VS2008 or develop your application with VS2005.