System.Runtime.InteropServices.COMException when running multiple interation of test with Kinect studio 2.0 RRS feed

  • Question

  • Dear all,

    We are developing a application using standard Kinect controls - Kinect V2, latest SDK.

    When doing manual testing everything is ok, when running multiple iterations of the same test with KinectStudio 2.0 we stumble upon a strange COM error from Kinect.dll. 

    We tried to reproduce the error and get an exact scenario but it is not possible. It happens randomly - usually somewhere between 10 and 70 iterations (loops) of the same short test. The stack trace doesn't give us any detailed information to where we could trace the error further... (copy of the exception details - got from Visual Studio is attached to the post).


    The main error message  goes as following:

    An unhandled exception of type 'System.InvalidOperationException' occurred in Microsoft.Kinect.dll
    Additional information: This API has returned an exception from an HRESULT: 0x8000000E

    What could be the problem, where should we look for errors. Could this be an issue with Kinect.dll and a bug in the library?

    If anyone has any ideas how to handle this further or where to look next - we would be very grateful for your advice.



    Monday, January 12, 2015 7:01 PM

All replies

  • The issue looks to be in the interactions library since that is where the callstack ends, but Kinect20 is the runtime. If the issue is occurring this lower down, I don't know that there is much you can do. It would be good to see if we can get crash dumps from you. Do you notice if KStudio crashes as well or other issues with the runtime happed(service restarts?)

    If you are able, can you create a dump of the crash using a tool like ProcDump. It would be good to attach the tool to KinectService, KStudioHostService as well as the application. The tool is lightweight enough that should be able to catch the crash in either of the processes.

    Once you have those, please email (k4w at Microsoft dot com) for instructions on how to upload that for us to have a look.

    Without having that information it would be difficult to assume anything. Are you able to reproduce in normal operation without KStudio?

    Carmine Sirignano - MSFT

    Monday, January 12, 2015 9:01 PM
  • Hi,

    thank you for quick reply and instructions. We managed to get a dump file from our app. KinectService and KStudioHostService did't crash.

    However we managed to get to the error only when running a "release" build. Under debug version it doesn't crash.

    So If we build a release we get a crash, usually under 10 iterations of KStudio tests.

    Looking at the dump file (we send and e-mail to k4w on instructions how to upload the dump file) we got the following description (see below). 

    Our release configuration is:


    Loading Dump File [C:\Procdump\AdoraMed.Assistant.exe_150113_212709.dmp]
    User Mini Dump File with Full Memory: Only application data is available

    Comment: '
    *** procdump  -64 -e -t -ma AdoraMed.Assistant.exe
    *** Unhandled exception: E0434352.CLR'
    Symbol search path is: *** Invalid ***
    * Symbol loading may be unreliable without a symbol search path.           *
    * Use .symfix to have the debugger choose a symbol path.                   *
    * After setting your symbol path, use .reload to refresh symbol locations. *
    Executable search path is: 
    Windows 8 Version 9600 MP (8 procs) Free x64
    Product: WinNt, suite: SingleUserTS
    Built by: 6.3.9600.17031 (winblue_gdr.140221-1952)
    Machine Name:
    Debug session time: Tue Jan 13 21:27:09.000 2015 (UTC + 1:00)
    System Uptime: 17 days 4:38:13.242
    Process Uptime: 0 days 0:04:51.000
    *** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll - 

    ************* Symbol Loading Error Summary **************
    Module name            Error
    ntdll                  The system cannot find the file specified

    You can troubleshoot most symbol related issues by turning on symbol loading diagnostics (!sym noisy) and repeating the command that caused symbols to be loaded.
    You should also verify that your symbol search path (.sympath) is correct.
    This dump file has an exception of interest stored in it.
    The stored exception information can be accessed via .ecxr.
    (1d68.3184): CLR exception - code e0434352 (first/second chance not available)
    The wow64exts extension must be loaded to access 32-bit state.
    .load wow64exts will do this if you haven't loaded it already.
    *** ERROR: Symbol file could not be found.  Defaulted to export symbols for wow64.dll - 
    0033:77151a91 <Effective machine and debuggee state conflict, disassembly not possible


    Tuesday, January 13, 2015 8:52 PM
  • The issue is because your application is trying to load the x86 binaries when the application build is x64. To enforce the correct files are used, change your application target build type to x64 or x86 specifically. Choose x64 if you have no other dependencies or third party libraries that are x86, otherwise to be safe, use x86.

    Carmine Sirignano - MSFT

    Wednesday, January 14, 2015 8:34 PM
  • Dear all,

    we have done that immediately when we so the error. However there is still the first error occurring, as mentioned in the first post. Please take a look at the last dump file we have sent to your k4w at microsoft dot com mail address.

    If you cant find it, please here is the link to the dump file:

    with kind regards



    Thursday, January 15, 2015 6:12 PM
  • How did you collect the dump file since there seems to be an issue with it? Can you re-capture the dump and be sure to use the -ma -e switches on the command line to make sure you get the full memory dump.

    Carmine Sirignano - MSFT

    Friday, January 16, 2015 5:49 PM
  • Sorry for late reply...

    We will recollect the dump file - and notify you again. Until then...




    Wednesday, January 28, 2015 11:46 AM