none
Kinect20.Face.dll crashes in repetitive testing of 3D model features RRS feed

  • Question

  • In my test harness under repetitive testing of 3D model features, I have reproducible Access Violation crashes in Kinect20.Face.dll.
    I can run this with or without App Verifier. The AV occurs 5-10 minutes after test begins.
    I do not delayload DLLs.

    Test harness:::::::::
    I have batch file which is infinitely looping.
    The loop is KSUtil playing a Kinect Studio 40 second recording with loop=2 and then timeout pausing for 5 seconds.
    The recording is of a man standing still and slowly rotating his head in the needed directions to build a face model.

    Application behavior::::::::::
    My app is using the color camera, face and faceHD apis. In particular:
    rawformat color frames
    retrieving face bounding box in colorspace
    rotation, translation, scale of head
    face animations and deformations
    modelbuilder to build model
    retrieved indices for triangles of model
    calculates vertices for model
    maps hdfacepoints enum vertices into 2d colorspace using a coord mapper
    All of the face code and APIs are on a dedicated worker thread. This thread is separate from the main UI thread.

    If I disable the 3D model features (deformations, model building, calls on build 3d model, etc.) then I do not get the AV crash.

    I have also noticed the crash might often occur shortly after a model builder is complete, GetFaceData() is successful and valid, and I request ProduceFaceModel() from that data.

    VS debugger (no App Verifier) attached to the process I get:::::::::::::::::::::::::

    First-chance exception at 0x00007FFFF8859D2D (Kinect20.Face.dll) in MaxRT.exe: 0xC0000005: Access violation writing location 0x000000002CD8FD36.
    Unhandled exception at 0x00007FFFF8859D2D (Kinect20.Face.dll) in MaxRT.exe: 0xC0000005: Access violation writing location 0x000000002CD8FD36.

    The Call Stack is:
    > Kinect20.Face.dll!00007ffff8859d2d() Unknown
    Kinect20.Face.dll!00007ffff88130c0() Unknown
    Kinect20.Face.dll!00007ffff8813e99() Unknown
    Kinect20.Face.dll!00007ffff88119af() Unknown
    Kinect20.Face.dll!00007ffff87ee0bb() Unknown
    Kinect20.Face.dll!00007ffff87e5d0c() Unknown
    Kinect20.Face.dll!00007ffff87e5a75() Unknown
    Kinect20.Face.dll!00007ffff87e5485() Unknown
    Kinect20.Face.dll!00007ffff87e5399() Unknown
    kernel32.dll!BaseThreadInitThunk() Unknown
    ntdll.dll!RtlUserThreadStart() Unknown


    App Verifier, I get what appears to be a veyr similar AV crash:::::::::::::::::::::::::::::::

    First-chance exception at 0x00007FFFF8989D2D (Kinect20.Face.x64.dll) in MaxRT.exe: 0xC0000005: Access violation writing location 0x00000001D13C76FF.
    =======================================
    VERIFIER STOP 0000000000000013: pid 0x180C: First chance access violation for current stack trace. 

    00000001D13C76FF : Invalid address causing the exception.
    00007FFFF8989D2D : Code address executing the invalid access.
    00000001BB33E2B0 : Exception record.
    00000001BB33DDC0 : Context record.


    The call stack is:
    > vrfcore.dll!00007ff80a2e3b94() Unknown
    vrfcore.dll!00007ff80a2e9f90() Unknown
    verifier.dll!VerifierStopMessage() Unknown
    ntdll.dll!RtlApplicationVerifierStop() Unknown
    vfbasics.dll!00007ff800d76835() Unknown
    vfbasics.dll!00007ff800d787fa() Unknown
    vfbasics.dll!00007ff800d77e2a() Unknown
    ntdll.dll!RtlpCallVectoredHandlers() Unknown
    ntdll.dll!RtlDispatchException() Unknown
    ntdll.dll!KiUserExceptionDispatch() Unknown
    Kinect20.Face.x64.dll!00007ffff8989d2d() Unknown
    Kinect20.Face.x64.dll!00007ffff89430c0() Unknown
    Kinect20.Face.x64.dll!00007ffff8943e99() Unknown
    Kinect20.Face.x64.dll!00007ffff89419af() Unknown
    Kinect20.Face.x64.dll!00007ffff891e0bb() Unknown
    Kinect20.Face.x64.dll!00007ffff8915d0c() Unknown
    Kinect20.Face.x64.dll!00007ffff8915a75() Unknown
    Kinect20.Face.x64.dll!00007ffff8915485() Unknown
    Kinect20.Face.x64.dll!00007ffff8915399() Unknown
    vfbasics.dll!00007ff800d8e28d() Unknown
    kernel32.dll!BaseThreadInitThunk() Unknown
    ntdll.dll!RtlUserThreadStart() Unknown


    --Dale



    • Edited by Dale Phurrough Sunday, December 7, 2014 11:01 AM clarified problem area
    Saturday, December 6, 2014 5:56 PM

All replies

  • I've further isolated it. Face DLL crashes shortly after:

         pFaceModelData->ProduceFaceModel(&pFaceModelCurrent);

    If there is no call to ProduceFaceModel(), then the crash does not occur.
    In the crash case above. The value 
    pFaceModelCurrent is always NULL.

    I believe the crash continues to be a private thread within Face DLL. I suspect this due to the call stack above.


    --Dale

    Sunday, December 7, 2014 6:04 PM
  • sent to the team. we may need to get the recordings from you if we can't repro.

    Carmine Sirignano - MSFT

    Monday, December 8, 2014 8:48 PM
  • I have a repro app and Studio stream I can provide you.
    It has the minimum number of Face APIs calls needed to create the crash.


    --Dale

    Tuesday, December 9, 2014 9:43 PM
  • will have the team setup a file space for you to upload the files. Look for an email with instructions later today.

    Carmine Sirignano - MSFT

    Wednesday, December 10, 2014 6:26 PM
  • I have uploaded two ZIP files with needed setup and info.
    FTM resume failed so there is a 3rd incomplete ZIP file there.

    --Dale

    Thursday, December 11, 2014 10:36 AM
  • Hi,

    Is there any news on this point ?

    I'm facing the same issue with the produceFaceModel function.

    Is there an update of the faulty dll ,or a workaround, or a try and catch (what to catch), ... ?

    Best regards

    Friday, July 31, 2015 7:47 AM
  • Here's what I know:

    • A subset of the Kinect team investigated this issue; in my evaluation the investigation was not exhaustive. Their priorities were not such to do a deep investigation on this issue.
    • The feedback that I got was that...yes, our code crashes, but it seems to only be when using a Kinect Studio recording on loop which doesn't have a clean entry and exit of the tracked body. That the crash is due to some Kinect subsystem state that wouldn't happen in real life.
    • I used a try/catch to attempt to gracefully handle a shutdown. I failed. The Kinect DLLs are interconnected and share state, so once this crash occurs, the whole Kinect subsystem is corrupted. If I remember correctly, it is so corrupted that sometimes you have to plug/unplug the Kinect from USB. After exploring this and seeing how useless the outcome, I chose to just let it crash.
    • My customers tend not to use Kinect v2 HD face tracking. I have never received a crash report from my customers. Why do they not use that feature? Because FACE HD IT IS TOO SLOW TO BE USEFUL. They tell me that the forced head movements are too jarring and length of time to move/build is too lengthy. They wish it had the speed of the v1 APIs.

    --Dale

    Friday, July 31, 2015 8:52 AM