Brand new at CUDA programming so please bear with me. I finally got cuda to work in console application using Visual studio 2008 on win xp (32 bit). But my main target is to port an existing program to port to cuda. This program is very computational intensive and is based on a complex gui. So, porting to cuda makes sense as it will cut down on my computational time significantly. I did some research and found no example where cuda is used with a forms based application. Its always been with a console application. But converting my gui into a console based application will be out of the question.
So, I tried doing a test (forms based gui) where I included the .cu file in my project. But on compile i get this linker error
fatal error LNK1313: ijw/native module detected; cannot link with pure modules
So I guess cuda doesn't play nice with managed code.
My question is: IS there anyway to use cuda with a form in visual studio 2008?
Another question: Has anyone even tried this as I have not seen any such example?
Please help....
Edit:--
Ok I changed the the properties->configuration->general->common language runtime support to /clr, and it compiled without any problem. But when I tried to run it i got a nasty popup dialog box with Debug Assertion failed error in file dbgheap.c, Expression _CRTisValidHeapPointer(pUserData).
So close but no cigar. Any Ideas?????
I've done this with a WPF application written in C# that used C++/CLI to interop with a mixed CLI/native assembly that in turn called CUDA code in a separate project. I've not tried WinForms but I don't see any reason why this shouldn't work. You end up writing quite a lot of plumbing code to handle the interop though.
I'd need more info about what your application was doing when __CRTisValidHeapPointer failed. Your heap has gotten corrupted somehow. It may or may not be related to CUDA code.
C# to C++ interop:
http://www.ademiller.com/blogs/tech/2009/09/c-optimization-revisited-part-3-the-native-option-c/
C++ and CUDA side-by-side:
http://www.ademiller.com/blogs/tech/2011/03/using-cuda-and-thrust-with-visual-studio-2010/
(Visual Studio 2010, CUDA 5.0) Try to set:
Linker->System->Subsystem: Not Set
Linker->Advanced->Entry Point: Empty
Related
I was super excited to see that the latest previews of .NET Core 3.1 and Visual Studio 2019 add support for managed C++/CLI projects, as such a project is the only think keeping a particular project on .NET Framework.
So, I installed Visual Studio Preview 16.4.0 Preview 4, along with the "C++/CLI support for v142..." options, and as expected I see the new C++ CLR templates and have .NET Core 3.1 preview 2 installed
I created a new project using the "CLR Class Library (.NET Core)" template, copied the files an old managed C++/CLI project, tweaked a little, and the assembly built - great!
However, when I try to use the assembly in a .NET Core 3.1, I get this fatal exception:
Unhandled exception. System.BadImageFormatException: Could not load file or assembly 'MyAssembly, Version=2019.0.1.0, Culture=neutral, PublicKeyToken=null'. An attempt was made to load a program with an incorrect format.
File name: 'MyAssembly, Version=2019.0.1.0, Culture=neutral, PublicKeyToken=null'
at TestApp.Program.Main(String[] args)
Both the managed assembly and test app target X64. Any ideas what could be the problem?
Someone from Microsoft provided the solution over on the Github repo.
When the managed C++/CLI project is built, a file ijwhost.dll is placed in the output folder alongside the assembly - this file needs to be deployed with the app that uses the assembly.
After putting ijwhost.dll in the same folder as the app, it worked as expected.
As an aside, the old C++/CLI project that I built against .NET Core 3.1 preview is actually quite complex - I'm very pleasantly surprised that it basically "just worked"!
Hopefully a better error message will be used in future!
I am using .net 5.0 as the CLI runtime. I finally found that the problem I have is missing native dependency DLLs.
For native applications, there will be an error prompt telling you which DLL is missing. While in .net core C++/CLI, they only give you a BadImageFormatException.
My solution is, create a pure native console project, paste the code that will cause BadImageFormatException, run it and see which DLL is missing then add it back to C++/CLI project file list.
I just found some unexpected dependencies.
In my case c# Net 5.0 app loads managed C++ dll, which is wrapping around unmanaged C++ dll.I get this error every time i try to run on on machine with no Visual Studio installed. I debugged it with ProcessMonitor and figure out that it can't found VCRUNTIME140D.dll. Found these dlls in my dev PC, copied them (both 32 and 64 bit versions) from my dev machine to customer's one to corresponded folders, and it made the trick. Hope will help somebody. Cheers.
I have to convert a C++ project from visual studio 2008 running on Windows XP to 2010 running on Seven. Compilation seems to run perfectly but during the debugging I have an error: "The program 'App.exe : Native' has exited with code -2146232576 (0x80131700)."
After a few researches on the internet I found out that the issue is in relation with .NET.
I tried to update my windows with hidden updates, check what the .NET version target is 4 and a few more things that doesn't work...
Has anyone ever encountered this issue ?
Thanks a lot.
EDIT: it is a managed C++ project
It is a low-level .NET initialization error, the CLR cannot get loaded. That's pretty hard to explain since you can run VS2010 without a problem and it already uses .NET version 4. The only decent guess is that you are actually using a C++ project (not a C++/CLI one) and that it loads the CLR itself. And asks for and old version, like 1.1, one that isn't installed on the machine. Search the code for "CorBindToRuntime".
Have you installed all Windows updates lately? If not, do so - seems to be some general .NET related error - see:
http://social.msdn.microsoft.com/Forums/ta/wlgeneraldev/thread/8f9d610f-92b2-4262-8e1a-88cee8428aed
You are running native code I presume? Are you?
If that is a case this error is caused by something else.
If you are using managed C++ than you have a problem related to the .Net framework.
Remember that some error numbers returned may (and they do) indicate different causes, depending who return an error.
Giving more information about what is your application doing and what language it is written would definitely help isolation problem.
sometimes I have to debug an application that was written with Borland C++ Builder. This application loads dlls compiled with Visual C++. Is there a debugger that can debug both parts of the application? Currently I have to decide - either I can easily set break points and see the source in Visual Studio or I have to start Borland C++, but I can't work with the source from the Visual-Studio compiled dll.
thank you for your help,
Tobias
You could try OllyDbg - version 1.x does not seem to support the latest Win version but there is also the 2.0 although it's still in alpha state(haven't tried myself that one yet).
EDIT - clarification:
Source debugging OllyDbg reads debugging information in Borland and
Microsoft formats. This information includes source code and names of
functions, labels, global and static variables. Support for dynamical
(stack) variables and structures is very limited.
The above is take from here.
UPDATE:
I'm not familiar with the Borland C++ Builder but at this link you can find some articles explaining how to deal with some interoperability issues between Borland and MS that might be of help.
if both parts built using ulink linker and have debug info you could try cdb32 debugger (from the ulink linker author)
cdb32 is still in its alpha stage though and I personally never tried such "mixed" debugging
Have you tried loading the DLL code in VS, loading the app code in BCB, and having both debuggers attached to the same running process at the same time? Not sure if Windows will allow that, but it might be worth a try.
I suspect there is no perfect answer to your question, you are going to have to compromise in some way, as I'm sure you are already doing.
I have a similar problem to yours at work. The applications that I work on are written in Python instead of Borland C++, but like your situation, these apps rely on a rather large Visual Studio compiled DLL for some functions.
My method of debugging these applications involves a combination of two debugging strategies: the use of an interactive debugger and the so called "printf" debugging technique.
What I basically do is pick one of the two areas as my main debug focus, and that determines my debugging approach:
If for a given situation I decide that I need to debug the DLL with greater detail, then I work with the VS debugger. I set the executable to run in the DLL project as my python script and that enables full debugging of the DLL code. If I need debugging support from the Python side, then I add print statements. If I need a breakpoint on the Python side to inspect some values, I just print all those values and immediately after call a C++ function that does nothing, but that has a breakpoint set in VS.
When I need to concentrate more on the Python side more I use a Python interactive debugger, but I have VS with the DLL project loaded on the side so that I can quickly add any necessary printfs on the DLL and recompile, so essentially the reverse of the above.
I know it's not the answer you expect, but it is a decent solution in my opinion.
It looks that it is possible to convert the debugging information generated by C++ Builder to a format understood by WinDbg (link to discussion). If so you could use it to debug both parts of your application (I haven't tried this though).
you can convert the .map files to Microsoft's debug file format
http://code.google.com/p/map2dbg/
now you can use Windebug; there is also a tool mentioned to convert to pdb format, so you could try the vc++ debugger
all, I have a rather frustrating issue. The application in question has an MFC GUI that uses the classes available in the MFC Featurepack. This GUI uses an DLL that is developed in C++\CLI. Our company uses Cruise Control. NET (1.4.4 SP1) on Windows Server 2008 SP2 for continuous integration. Cruise Control is setup to use the version of MSBuild that comes with the 3.5 version on the framework.
The issue in question is that if I use the build that Cruise Controls creates, I receive the following error: "Unhandled exception at 0x7642fbae (kernel32.dll) in FormView.exe: 0xE0434F4D: 0xe0434f4d." After some digging, the issue seems to be that the GUI doesn't like the C++\CLI assembly.
The "gotcha" is that if I log on to the server, and, using PowerShell, execute the same MSBuild command, the build works. Any one have ideas?
The issue was how I was building the installer. It was a separate solution from the project's main solution, and was thus a separate task from the primary build. Therefore, the output assemblies got signed twice, and loader complained because the one the application wanted was no longer valid.
you could try and attach the process to the visual studio debugger.
At my shop, the main product app is a mongrel built on MFC, QT and other random things devs have thrown in over the years.
In the current stack, Qt toolkit is on the way out, but still features heavily.
If I have SQL 2005 Management studio open and have to do a full build, it usually hangs a CPU (even after the offending process is taken out back and shot...) during the qt specific parts of the build (Moc'ing and UIC'ing)
has anyone seen anything like this? any ideas what the problem could be?
In my experience, some of these tools are capable of looping forever (qt4: lupdate/lrelease for sure).