WinForms with CUDA 8 Crashes

Upgraded to Cuda 8 from 7.5. Also now using Visual Studio 2015. My app has been running fine on Cuda 7.5 and VS 2013. Now it crashes upon start-up with ‘ntdll.dll’ squawking about memory exception.

To troubleshoot i have created a tiny app that opens a window and calls a simple cuda routine from cuda samples.If I run just the WinForms app it works. If I run just the cuda sample app it runs correctly. but when I integrate the cuda routine into the WinForms app it crashes on startup (that is, before even the first line of the main is reached).

Would appreciate any help or insights you all can give.

thanks

I have learned a lot more since first post: [i will try to attach some screen shots too]

  • ntdll crashes in routine ‘RtlValidateHeap’ which is requested from ucrtbased.dll
  • this is happening during the preamble before the app gets control.
  • the version of ntdll.dll is from the SYSWOW64 folder, version 10.0.14393.479 from nov 11, 2016 [see gif]

My conclusion is that Cuda 8 libraries have a bug that is crapping up the heap, from which all else follows. Again, this behavior is not happening when I delete the *.cu routine from my app; when I include the *.cu routine BUT comment out any calls to it the error still occurs. In either event, the same ntdll.dll is used.

I would like to hear from Nvidia – is it possible i need a different version of some windows?

If you would like to hear from NVIDIA, I would suggest filing a bug report, as these forums are not designed as (nor usually function as) an official bug reporting channel. The bug reporting form is linked from the CUDA registered developer website. If you are not a registered developer yet, the application is easy, and approval usually occurs within one business day (relative to US West Coast time zone).

Note: NVIDIA’s bug reporting mechanism contains checks for abuse that can generate false positives and prevent you form filing; at any given time it usually also contains one or even several bugs. A suitable strategy is usually to file a simple bug report, stating that you will add supporting material in a separate pass. Then add files, images etc later.

thanks for the reply. i cannot find a page for reporting bugs, especially windows related bugs. could you please provide a url? searching for ‘bug report’ only brings up Linux related material.

[url]https://developer.nvidia.com/[/url], then login with your registered developer information. I just logged in myself, the site is operational.

Once logged in, click on “My Programs” then “NVIDIA Developer Program”. Now click “Member Area” and finally click on “Report a Bug”.

many thanks

Could there be a mixup in debug/release DLLs?

The use of ucrtbased.dll seems to indicate that you are running a debug build of your program.

As far as I know this would require that every component of your project be built in Debug mode.
Is this the case?

cbuchner1 – thanks for trying to help out. But do know this for a fact? What I know is that the difference between debug and production dlls [or anything else] is the inclusion of symbol tables. they both execute the same algorithms and hence arrive at the same result. I frequently mix debug and production libraries in my work.

I have myself run into the problem cbuchner1 is mentioning. You only have to do a tiny bit of searching on the web to find numerous people who suggest that mixing debug and release DLLs is a bad idea.

[url]use of release dll's in debug build

[url]c++ - Mixing debug and release library/binary - bad practice? - Stack Overflow

Whether it has any bearing on your problem, I can’t say.

I frequently mix debug and production libraries in my work.

That’s like driving without seat belt. Works just fine most of the time - until it doesn’t.

What I know is that the difference between debug and production dlls [or anything else] is the inclusion of symbol tables. they both execute the same algorithms and hence arrive at the same result.

Apart from the fact that

…in-memory layout of data structures (in particular STL objects) differs due to added support for iterator checks and extra debugging features.

…different memory allocators are used in Debug builds where the Debug Heap may insert extra guard data in front and after memory allocations

things are really not that different.

You just got burnt probably because of said issues. Time to drive with seat belts on ;)