A C++ AMP deployment question RRS feed

  • Question

  • I've copied the vcamp110.dll, msvcr110.dll and
    msvcp110.dll to the local directory, but the gpu code simply crashes on the target install machine.  I've got Direct X 11 installed.  Is there anything else I need to do?

    Thursday, April 19, 2012 11:20 PM


  • I think I've found it.  Our installer is setting a compatibility flag.  I think we just need to run as administrator.  I switched this off on the test machine and am now running.  Will run it past beta testers now.

    Wow.  i spent almost a week on that.

    Thursday, April 26, 2012 4:50 PM

All replies

  • Hi Dan,

    The instruction Daniel gave applies to the binary that is built using "Release" configuration in visual studio. Maybe your binary was built from the "Debug" configuration?



    Thursday, April 19, 2012 11:32 PM
  • Hi Dan

    Please read our deployment description here: http://blogs.msdn.com/b/nativeconcurrency/archive/2012/03/12/deploying-apps-built-with-c-amp.aspx

    If your C++ AMP is crashing (regardless whether it is on remote or local machine) please catch the exception so you can see why it is crashing. More on exceptions here: http://blogs.msdn.com/b/nativeconcurrency/archive/2012/01/27/c-amp-runtime-exceptions.aspx

    BTW, you said you have DirectX 11 installed - DirectX 11 is always installed on Windows systems that we support. What you need is a DirectX 11 target, e.g. a GPU with a DirectX 11 driver.

    Let us know if any of the suggestions above lead you to an answer or not.



    Friday, April 20, 2012 1:05 AM
  • 'Release' is my active configuration

    I'm building on an AMD A4, and the code runs fine there, and I'm trying to install on an AMD c-60, which I believe also has an integrated gpu.  Also beta testers are trying to install on a number of configurations with no success so far.

    I'm a little confused if I should install the 32 or 64 bit versions.  I'm developing a 32 bit dll that needs to run on 32 bit and 64 bit systems, although most of our testers are on 64 bit Windows.  In fact I could forgo the 32 bit system support for now if I had to.

    Also, are there other C++ related dependencies I could be missing that aren't related to AMP?  I'm keeping this a very simple dll with only 2 functions and the following includes and options:

    #include <float.h>
    #include <amp.h>
    using namespace concurrency;

    Friday, April 20, 2012 11:15 PM
  • Hi Dan,

    Could you give us a little bit more detail? Assume the binary you build is 32-bit.

    1. On your dev machine, where did you get the vcamp110.dll etc?

    2. On your target machine, where did you copy your binary and where did you copy the vcamp110.dll etc.?



    Friday, April 20, 2012 11:20 PM
  • This was the source on the dev machine "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\redist\x86\Microsoft.VC110.CXXAMP\vcamp110.dll"

    And on a 64 bit system, the files are bing copied to the same folder under

    C:\Program Files (x86)\NameOfFolder\

    Friday, April 20, 2012 11:31 PM
  • Ok, so I've had one report that it's crashing on 32 bit system as well if any of this helps

    roblem signature:
      Problem Event Name:    APPCRASH
      Application Name:    dogwaffle.exe
      Application Version:
      Application Timestamp:    4f9052b6
      Fault Module Name:    KERNELBASE.dll
      Fault Module Version:    6.1.7600.16850
      Fault Module Timestamp:    4e21132b
      Exception Code:    e06d7363
      Exception Offset:    00009673
      OS Version:    6.1.7600.
      Locale ID:    1033
      Additional Information 1:    c625
      Additional Information 2:    c6259140a8bbb87c91cd242b10e93dfb
      Additional Information 3:    508a
      Additional Information 4:    508a35a2af63cb201ec8ec79a8200363

    Saturday, April 21, 2012 12:12 AM
  • Dan, do you have exception handling (as per the link I shared)? That may help narrow down if this is code-related or environment/setup-related.




    Saturday, April 21, 2012 2:05 AM
  • I put my parallel_for_each block inside a try/catch as indicated but the results are the same, just crashes on the test machine.  Still runs fine on the development machine.
    Saturday, April 21, 2012 10:32 PM
  • I simplified the code so I don't think that's the problem.  Still runs fine on the development machine and crashes on the deployed machine. There's some dependency not being met somewhere.

    void __stdcall GPUNothing(){
        int x;
        extent<1> ext(80);;
       parallel_for_each(ext, [=](index<1> idx) restrict(amp)
           int y = x;
    catch(runtime_exception& ex)
       MessageBox(NULL,ex.what(),"Error junk",MB_OK);

    Saturday, April 21, 2012 11:12 PM
  • I've verified that my gpu has a directx11 driver according to the utility on this page http://blogs.msdn.com/b/nativeconcurrency/archive/2011/09/22/can-i-run-c-amp-on-my-device.aspx

    Sunday, April 22, 2012 5:08 PM
  • Hi Dan

    Thanks for adding exception handling, and confirming that you are trying on DirectX 11 hardware. I agree there appears to be some environment issue. The C++ AMP runtime only depends on the two DLLs that the blog post mentions. So I cannot guess what else is going wrong with your deployment. Next, let’s make sure that C++ AMP deployment is the issue instead of something more generic.

    Can you try deploying a C++ application built with Visual Studio 11 Beta that uses other C++ 11 features, but not C++ AMP? In other words, try something that demonstrates that you are deploying the 2 other VS 11 C++ dlls correctly, without C++ AMP being in the picture at all.



    Sunday, April 22, 2012 7:10 PM
  • I added this function inside the same dll.  It's not complicated, but it does run on the target machine without crashing.

    void __stdcall TestGUPDLL (long Hi) {for (int n=0;n<Hi;n++){int n2=n;}
    MessageBox(NULL,"Did some stuff","No error",MB_OK);}

    Sunday, April 22, 2012 10:47 PM
  • Hi Dan,

    Could you please modify your TestGUPDLL function to something like this:

    #include <vector>
    #include <iostream>

    void __stdcall TestGUPDLL (std::vector<int> &a, int Hi)
       for (int n=0;n<Hi;n++){a[n]=n;}
       std::cout << "Did some stuff" << std::endl;

    Build it and try the deploy again to see if it crashes on your target machine? If it does, it suggests the crash is a more generic issue not related to AMP. Otherwise, could you please package your simple deploy example (with the DLL that uses AMP, and the DLLs you try to deploy with it) and share it with us, so we can investigate.

    Also there is a tool called dumpbin that is available at

    C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\dumpbin.exe

    You can use "dumpbin /dependents my.dll" to see what my.dll depends on.



    Monday, April 23, 2012 5:28 PM
  • I'm seeing one thing that's odd with dependency walker.  on the development machine, all the dependencies are showing up as 32 bit, but most of them are showing up as 64 on the target machine.  I'm positive I've copied them from the x86 folder.

    • Proposed as answer by Zhu, Weirong Tuesday, April 24, 2012 4:34 PM
    • Unproposed as answer by Zhu, Weirong Tuesday, April 24, 2012 4:34 PM
    Tuesday, April 24, 2012 3:14 PM
  • Hi Dan,

    Have you got chance to try the experiment I suggested above, so we can tell whether it's an AMP issue or a more generic issue.



    Tuesday, April 24, 2012 4:35 PM
  • That's my next step
    Tuesday, April 24, 2012 6:24 PM
  • I can't get the non AMP functions to crash on the target machine

    As far as sharing a deployment, that might be tough as it's 30 megs and a commercial product.

    Tuesday, April 24, 2012 9:06 PM
  • Hi Dan

    Can you try deploying the ZIP file, which is inside the ZIP file here: http://www.danielmoth.com/Blog/DeployAMP.zip

    Just unzip the inner ZIP file on the target machine and execute the EXE. Let us know the results (what you see in the console, or what error message you see)



    Wednesday, April 25, 2012 2:23 AM
  • Your exe ran on the target machine.  I recompiled it and that ran too.

    This is getting frustrating.  Maybe I'm just doing something fundamentally wrong.

    Here's an example of my code.  This runs on the developement machine and crashes on the deployment machine.

    //float x0=-1,y0=-1;
    //float x1=1,y1=1;

    //w/h =width/height

    //buf is a pointer to a 1-d int array of (w*h)

    void __stdcall GPU_Mandelbrot(int w, int h,  float x0, float y0, float x1, float y1,int depth, int * buf){

        array_view<int, 2> bbuf(h, w, buf);  
        bbuf.discard_data();//doesn't need to be copied to GPU memory

    float dx  = x1 - x0;
    float dy = y1 - y0;
    float scli=255.0f/(float)depth;
    float recipw=1.0f/(float)w;
    float reciph=1.0f/(float)h;

        parallel_for_each(bbuf.extent,[=](index<2> idx) restrict(amp){
    // Mandelbrot
    int i,x,y;
    float r,n,b,e,yxr,d;
        r = 0.0f ; n = 0.0f ; b = ((float)x * recipw )* dx + x0 ; e = yxr * dy + y0 ; i = 0;
                    while (((i < depth) && ((r * r) < 4.0f)))
                    {d = r ; r = r * r - n * n + b ; n = 2 * d * n + e ; i ++;}
        bbuf[idx] = (int)((float)i*scli);
    catch(accelerator_view_removed& ex)
    // do something about it;


    Wednesday, April 25, 2012 4:26 PM
  • Hi Dan

    Sorry that this is getting frustrating for you and it is good that we are making progress. We now know that there is nothing wrong with C++ AMP deployment on your machines, but rather the problem is with your app somewhere.

    In the code you shared, can you please make two changes and try again:

    1. Catch a more generic exception. Right now you are only catching a very specific one. See the code I shared for how to do that and how to output the exception message.
    2. After this entire code, but before returning from GPU_Mandelbrot, try to access the results of the computation. For example, add the single statement bbuf.synchronize(); And also wrap that in a try..catch block just like you will do for the parallel_for_each.

    Hopefully that will tell us exactly what is going wrong, if the problem is with this piece of code...



    Wednesday, April 25, 2012 8:14 PM
  • As soon as I put your code in a dll and called it, it started crashing again.

    In fact, I made a parallel_For_Each with a single thread, and no code whatsoever, and that crashes, while it all runs fine on the development machine.

    I'd say AMP just won't run on this machine, but your code ran when it was in an exe.

    Thursday, April 26, 2012 1:38 AM
  • incidentally, I got visual studio installed on this machine I've been trying to deploy on so I didn't have to go through all the copying back and forth.

    and when I crashed, i used the debugger, and it appears to be crashing before something "is handed over to the OS" ...

    : Microsoft C++ exception: Concurrency::scheduler_resource_allocation_error at memory location 0x0018ECE0.

    and this was the code that came up..

            // Hand it off to the OS:

    #if defined(_M_X64) && defined(_NTSUBSET_)
            RtlRaiseException( (PEXCEPTION_RECORD) &ThisException );
            RaiseException( ThisException.ExceptionCode,
                            (PULONG_PTR)&ThisException.params );
    }  <----- And this was the breakpoint...

    Thursday, April 26, 2012 1:44 AM
  • Thanks Dan. This information helps a little. A few questions and suggestions to help troubleshoot this:

    1) Is your deployment machine running Windows 8?

    2) Can you try changing /MT to /MD and see if it makes a difference?

    3) I presume you have aready confirmed that on removing the parallel_for_each, the crash goes away? Can you remove the parallel_for_each and instead insert the following code to see if the problem repros (And put a call to Foo() in a code path that is executed.):

    #include <ppl.h>
    #include <array>
    #include <sstream>
    #include <iostream>

    using namespace Concurrency;
    using namespace std;

    void Foo()
       // Print each value from 1 to 5 in parallel.
       parallel_for(1, 6, [](int value) {
          wstringstream ss;
          ss << value << L' ';
          wcout << ss.str();

    - Amit

    Amit K Agarwal

    Thursday, April 26, 2012 6:47 AM
  • I think I've found it.  Our installer is setting a compatibility flag.  I think we just need to run as administrator.  I switched this off on the test machine and am now running.  Will run it past beta testers now.

    Wow.  i spent almost a week on that.

    Thursday, April 26, 2012 4:50 PM