none
Kinect Studio crashes XNA application‎s RRS feed

  • Question

  • When I try to connect Kinect Studio to an XNA application the app crashes.
    I tested it with the Samples from the Developer Toolkit.

    I use VS2010 and W7 64bit and a Kinect for Xbox.

    The WPF examples are running fine.
    The Error I get when running the XNABasics example is following (Sorry its partly in German):
    Problemsignatur:
      Problemereignisname:    APPCRASH
      Anwendungsname:    XnaBasics.exe
      Anwendungsversion:    1.0.0.0
      Anwendungszeitstempel:    504a7d42
      Fehlermodulname:    KinectStudioConnector32.dll
      Fehlermodulversion:    1.5.2.222
      Fehlermodulzeitstempel:    5015e310
      Ausnahmecode:    c0000005
      Ausnahmeoffset:    00007198
      Betriebsystemversion:    6.1.7601.2.1.0.256.48
      Gebietsschema-ID:    1031
      Zusatzinformation 1:    867d
      Zusatzinformation 2:    867dcfba8c79c419cc83e8596b854db9
      Zusatzinformation 3:    614f
      Zusatzinformation 4:    614fd16b3adacbd899bb6a7de15896be

    When I last run it about a week ago everything was working fine.
    Could it be because of a graphic card driver update or something similar?

    //Edit 1:
    I reinstalled  Kinect SDK, the Toolkit XNA Studio but no change.
    But I noticed that it only crashes when I run it from inside Visual Studio.
    Starting the .exe (Debug or Release) from the folder and connecting works alright.

    //Edit 2:
    Thanks to Sashkic14 for the Idea.
    I just took the Kinect Studio 1.5.1.0 from the 1.5.1 SDK.
    The rest of 1.5.2 seems Works fine.

    Hope the Kinect for Windows update next Month will fix this :-)



    Friday, September 7, 2012 11:34 PM

Answers

  • The workaround is to set the following environment variable before starting your debugger:

    _NO_DEBUG_HEAP=1

    And then everything will work fine. 

    Basically, KinectStudioConnectorXX.dll depends on a “normal” heap memory layout, which is not a valid assumption when an application runs under a debugger.  This is why everything works fine when you start without a debugger:  The debug heap is not used, and the memory is layout is as expected.

    We are now tracking this issue for possible fix in a future release.


    • Edited by Abecedarian Wednesday, September 19, 2012 6:44 PM
    • Proposed as answer by Abecedarian Wednesday, September 19, 2012 6:44 PM
    • Marked as answer by Markus Jupiter Wednesday, October 3, 2012 4:37 PM
    Wednesday, September 19, 2012 6:43 PM

All replies

  • Hi,

    I have the similar problem.
    I've  updated Kinect SDK Developer Toolkit to version 1.5.2. When I build SkeletalViewer application with VS 2010, run it in debug mode, and connect it to Kinect Studio, the application crashes (I can not debug it properly, it's says something about ntdll.dll). SkeletalViewer.exe release and debug application work fine if they are run from the Debug/Release directory. In the previous version of KinectSDK,  1.5.1., everything was working normally.

    I'm using 64-bit Windows, latest update, and SP1 of VS 2010.

    .....No solution found.

    In the end, I've uninstalled Kinect SDK Developer Toolkit version 1.5.2. and returned back to the previous version.

    Unfortunately, I'm using Kinect for Xbox and perhaps this can be the cause of the problems. I wanted to report it, but it's unfair since Kinect SDK Developer Toolkit is exclusively aimed for Kinect for Windows. If you are using Kinect for Windows, this could be a serious bug.

    Sunday, September 9, 2012 10:00 AM
  • I also see the crash that Sashkic mentioned. Checked a few things about the problem and I've got some insight. I don't know what the bug
    is, but I don't need to let it stop me debugging the app with both Kinect Studio and Visual Studio.

    There is a workaround to this bug that I have discovered. First start the SkeletonViewer.exe manually (from the debug folder), then connect it to Kinect Studio 1.5.2. Finally, switch to Visual Studio and select Debug>Attach to Process and select SkeletonViewer.exe. Voila!

    Awkward, kludgy, but it does the job.

    As a parenthetical note, when I run Kinect Studio as administrator, the application doesn't crash anymore, but I don't see the streams show up in Kinect Studio either. I realize this is because both the application and Kinect Studio must be started with the same permissions level (http://msdn.microsoft.com/en-us/library/hh855390). This means that you've got to make sure that you are running Visual Studio, Kinect Studio and the .exe with the same permissions level for my workaround to succeed.


    • Edited by twocs Tuesday, September 11, 2012 6:49 AM minor edit
    Tuesday, September 11, 2012 6:49 AM
  • By the way, I'd assume it's the same bug with XNABasics. The big difference is that with XNABasics, the crash is intercepted and does not go to the Visual Studio that was used to launch the debugging session.

    When I try to debug, I see the funny warning: "A debugger is attached to XnaBasics.exe but not configured to debug this unhandled exception. To debug this exception, detach the current debugger."

    If I do detach the current debugger and try to look in Visual Studio, I find that the error is: "Unhandled exception at 0x04df7198 in XnaBasics.exe: 0xC0000005: Access violation reading location 0xbaadf054." This error 0xC0000005 is a buffer overrun error, which means that the program was trying to look at memory that is not allocated to the process. For example, if there is a 10 character long string, and the system tries to look at character 55, you would see this error. See http://blogs.msdn.com/b/calvin_hsia/archive/2004/06/30/170344.aspx for info about this error.

    As the bug is in KinectStudioConnector64.dll, for which there is no source available to us even though it seems to be just a compiled header, we can only poke around with the debugger. For SkeletalViewer, I can see that the thread CSkeletalViewerApp::Nui_ProcessThread is usually sitting on a blocking call such as:

    nEventIdx = WaitForMultipleObjects( numEvents, hEvents, FALSE, 100 );

    or

    HRESULT hr = m_pNuiSensor->NuiImageStreamGetNextFrame( m_pVideoStreamHandle, 0, &imageFrame );

    It furthermore always seems to occur in SensorLink::ReceiveControlProc that is called in KinectStudioConnector64.dll.

    Finally, we see that there is a malloc in the stack frame. Apparently the new version is not threadsafe, and can guess that KinectStudioConnector64.dll is trying to access some memory that is not yet allocated. Until they patch it up, maybe we must go back to the old version or try the workaround I proposed in my last post.


    • Edited by twocs Tuesday, September 11, 2012 7:45 AM another detail
    Tuesday, September 11, 2012 7:34 AM
  • I am seeing the same error (0xC0000005: Access violation reading location 0xbaadf054.) for the following applications:

    Depth Basics-D2D
    Depth-D3D
    DepthWithColor-D3D

    To reproduce:
    1. Start an application
    2. Start Kinect Studio
    3. Select Connect to Process
    4. Load a pre-recorded file
    5. Hit "Play in Application" (Ctrl + A)

    Incidentally, I also see the same error when running my own project, which uses the C++ Nui API + OpenFrameworks. The workaround that works for me is similar to what twocs suggested:

    1. Go to your bin folder where your project is built.
    2. Run application directly.
    3. Connect via Kinect Studio, everything works fine. 

    Very strange bug!

    Wednesday, September 19, 2012 3:04 PM
  • The workaround is to set the following environment variable before starting your debugger:

    _NO_DEBUG_HEAP=1

    And then everything will work fine. 

    Basically, KinectStudioConnectorXX.dll depends on a “normal” heap memory layout, which is not a valid assumption when an application runs under a debugger.  This is why everything works fine when you start without a debugger:  The debug heap is not used, and the memory is layout is as expected.

    We are now tracking this issue for possible fix in a future release.


    • Edited by Abecedarian Wednesday, September 19, 2012 6:44 PM
    • Proposed as answer by Abecedarian Wednesday, September 19, 2012 6:44 PM
    • Marked as answer by Markus Jupiter Wednesday, October 3, 2012 4:37 PM
    Wednesday, September 19, 2012 6:43 PM