locked
App failing WACK test because of Microphone use RRS feed

  • Question

  • We've got an app that's been in the store for over a year now, and it's recently begun failing the WACK 3.1 test so the update can't make it into the store.  Apparently, it fails only on ARM (but of course not here on my surface).

    I'm finding it impossible to get to the bottom of it with the test guys.

    Here's the scenario of how the App (Tune Up http://apps.microsoft.com/webpdp/app/tune-up/18337b4f-72f6-4fa0-8502-c19edf7203cd ) works.

    When the program first starts, it tries to open the microphone (as it's only job is to process audio).

    If it fails, we handle the access denied error.

    The problem is that the very first time the program is run on a device, the OS (8.1) throws up a message requesting microphone permission.  If this is displayed during the wack test, if fails with this:
    ReportDescription=A problem caused this program to stop interacting with Windows.

    DynamicSig[1].Name=OS Version
    DynamicSig[1].Value=6.3.9600.2.0.0.256.97
    DynamicSig[2].Name=Locale ID
    DynamicSig[2].Value=1033
    DynamicSig[22].Name=Additional Hang Signature 1
    DynamicSig[22].Value=6f3133fe9a34410bde59edbf0dd78e9d
    DynamicSig[23].Name=Additional Hang Signature 2
    DynamicSig[23].Value=9302
    DynamicSig[24].Name=Additional Hang Signature 3
    DynamicSig[24].Value=9302c294c4b2792601ed32dc049c4e20
    DynamicSig[25].Name=Additional Hang Signature 4
    DynamicSig[25].Value=6f31
    DynamicSig[26].Name=Additional Hang Signature 5
    DynamicSig[26].Value=6f3133fe9a34410bde59edbf0dd78e9d
    DynamicSig[27].Name=Additional Hang Signature 6
    DynamicSig[27].Value=9302
    DynamicSig[28].Name=Additional Hang Signature 7
    DynamicSig[28].Value=9302c294c4b2792601ed32dc049c4e20
    UI[3]=TuneUp is not responding
    UI[4]=If you close the program, you might lose information.
    UI[5]=Close the program
    UI[6]=Close the program

    I've asked repeatedly in the test instructions for the testers to do one simple thing but they don't seem to indicate that they have in the crash reports.

    "Using the Windows App Certification Kit on a Windows RT system with this app, we couldn't get passing results when tested. Unfortunately, when our reviewers tried to launch your app failed to launch every time.  Our reviewers were unable to complete a review. If we were able to capture a crash report, we have provided it to you. Please see: http://go.microsoft.com/fwlink/?LinkId=279806 for information on how to work with the crash reports. "

    Here's my request to the testers from the notes.  I don't think I can be any clearer.

    Do you guys even read this?
    A problem caused this program to stop interacting with Windows.
    This is definitely caused by the wack test not detecting that win 8 has requested the user to ask for mic permission. This isn't something I can detect, and only happens the first time the program is run.
    PLEASE, PLEASE run the program once before running the wack test, and you'll see it will pass.   That's exactly what I see on my surface and on my x86 tablet too.  This isn't a real failure, it's an artifact of the WACK Test.


    WIN RT WACK TEST FAILURE.
    Please do the following.
    Install the App on RT.
    Run the app once, to get past the microphone permission blocking the app (you can say no)
    Run the WACK TEST.  It works fine here in that case.


    RECENT WIN RT FAILURE.  Please see below.  It appears to be the same thing.

    Regarding the recent failures, if you are seeing the app hanging, it is caused by the microphone permission not being granted, and WACK not figuring it out. 

    Please run the app, and give it permission to use the microphone before testing.
    Otherwise the message box from the OS pops up, and the app appears unresponsive.

    *************************


    Anthony Wieser | Wieser Software Ltd | www.wieser-software.com

    Friday, January 10, 2014 8:26 AM

Answers

  • Go here:
    https://getsupport.microsoft.com/default.aspx?locale=EN-US&supportregion=EN-US&ccfcode=US&mkt=EN-US&pesid=14654&oaspworkflow=start_1.0.0.0&tenant=store&supporttopic_L1=31762156&supporttopic_L2=31762161&ccsid=635249371875470219

    Ensure that "Problem type" is set to "App submission and certification", while "Category" is set to "app certification results".  then click "Call me" and fill out the information.

    You'll get a publishing support case where the engineers will assign a case number and call you back. Please let me know if you have any further problems.


    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Friday, January 10, 2014 4:05 PM
    Moderator
  • I've managed to come up with a solution that isn't too terrible, though I preferred the original behaviour.

    It turns out the OS supplied permission message only appears if the mic is opened from the UI thread.

    As a result, when the program starts, it requests the mic object to be
    initialized from a non-ui thread, which fails silently, but it can detect that
    the microphone has not started, and shows the same UI as if permission had been
    denied with a notice as to how to fix the problem (grant permission, plug in
    mic, etc), and a try again button.

    When you press the try again button, the mic is initialized from the ui
    thread, so if it's the first time and you haven't granted permission, the os
    does it.  If you have already granted it manually via the settings  it just works, and the permission is remembered.

    But it would be nice if the UI could react to the permissions and realize
    that it has been denied (as opposed to being disconnected, no mic, etc). 
    Fingers crossed it passes certification this time.

    When I initially ran the WACK test on my Surface it failed on the performance suspend
    test.  It turns out this was because my dev license on that machine expired on
    Jan 25th, wasting still more of my time.  I can't imagine why it's for such a
    short time, only 3 months?!


    Anthony Wieser | Wieser Software Ltd | www.wieser-software.com

    Friday, January 31, 2014 10:30 PM

All replies

  • Anthony - have you opened a publishing support case for this issue?  If so, can you send us the case number?

    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Friday, January 10, 2014 1:38 PM
    Moderator
  • No, because I can't figure out how to do that.  All roads seem to lead to a payment request.


    Anthony Wieser | Wieser Software Ltd | www.wieser-software.com

    Friday, January 10, 2014 3:39 PM
  • Go here:
    https://getsupport.microsoft.com/default.aspx?locale=EN-US&supportregion=EN-US&ccfcode=US&mkt=EN-US&pesid=14654&oaspworkflow=start_1.0.0.0&tenant=store&supporttopic_L1=31762156&supporttopic_L2=31762161&ccsid=635249371875470219

    Ensure that "Problem type" is set to "App submission and certification", while "Category" is set to "app certification results".  then click "Call me" and fill out the information.

    You'll get a publishing support case where the engineers will assign a case number and call you back. Please let me know if you have any further problems.


    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Friday, January 10, 2014 4:05 PM
    Moderator
  • SRX1230524922ID is the case number, though I'm not happy with the outcome.

    Basically, I'm being told I have to change my app, so that it doesn't open the microphone automatically the first time the app runs.  But windows 8.1 pops up the permissions dialog, and that is what is blocking the WACK test, not my code.

    Can you please get someone to have a look at the details.  I won't be the only one affected, and the UX that working around WACK will require will put off users.


    Anthony Wieser | Wieser Software Ltd | www.wieser-software.com

    Monday, January 20, 2014 5:28 PM
  • I'll check on this.

    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Tuesday, January 21, 2014 2:34 PM
    Moderator
  • Thanks Matt.

    Anthony Wieser | Wieser Software Ltd | www.wieser-software.com

    Tuesday, January 21, 2014 2:44 PM
  • I've managed to come up with a solution that isn't too terrible, though I preferred the original behaviour.

    It turns out the OS supplied permission message only appears if the mic is opened from the UI thread.

    As a result, when the program starts, it requests the mic object to be
    initialized from a non-ui thread, which fails silently, but it can detect that
    the microphone has not started, and shows the same UI as if permission had been
    denied with a notice as to how to fix the problem (grant permission, plug in
    mic, etc), and a try again button.

    When you press the try again button, the mic is initialized from the ui
    thread, so if it's the first time and you haven't granted permission, the os
    does it.  If you have already granted it manually via the settings  it just works, and the permission is remembered.

    But it would be nice if the UI could react to the permissions and realize
    that it has been denied (as opposed to being disconnected, no mic, etc). 
    Fingers crossed it passes certification this time.

    When I initially ran the WACK test on my Surface it failed on the performance suspend
    test.  It turns out this was because my dev license on that machine expired on
    Jan 25th, wasting still more of my time.  I can't imagine why it's for such a
    short time, only 3 months?!


    Anthony Wieser | Wieser Software Ltd | www.wieser-software.com

    Friday, January 31, 2014 10:30 PM