locked
[RTM] Error 0x80073D05 while running application certification tool RRS feed

  • Question

  • Hi,
    on the RP the app was working well.
    Now I installed a clean install of Win8RTM + VS2012 RTM.
    I followed the guidelines for upgrading the project (fixed the manifest) and the application worked perfectly.

    When running the Wack I receive this error:

    0x80073D05  ERROR_DELETING_EXISTING_APPLICATIONDATA_STORE_FAILED
    An error occurred while deleting the package's previously existing application data.

    What does it mean?

    Thanks


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele

    Thursday, August 16, 2012 11:40 AM

All replies

  • I believe I understood the problem.

    The problem is the RoamingState folder in userprofile\AppData\Local\Packages\ApplicationName_XXXX that can't be deleted. When the Wack tried to uninstall the app, it failed.

    The ACL for that folder are totally sealed (probably due to a system or higher integrity level). I suspect that the self-signed certificate of the app was used to seal the security for that folder and that, for some reason I still don't know, the system could create but not delete that folder.

    Re-generating the self-signed certificate (coming from the RP), solve the problem because it creates a new folder for the app (ApplicationName_YYYY)

    The downside is that the old application folder stay there and cannot be erased (the app is uninstalled but having failed the uninstall, the folder is still there).

    So now the question is: Is there any tool / powershell cmdlet / other to delete those folder?

    I also strongly suggest to give a verbose description of the possible causes of the problem so that developers won't waste time in diagnosing the problem.

    Thanks


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele

    Thursday, August 16, 2012 5:37 PM
  • Let's retry.

    The question was: Is there any tool / powershell cmdlet / other to delete the application's folder which went "lost" due to the change of identity?

    Thanks


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele

    Tuesday, August 21, 2012 4:04 PM
  • Raffaele,

    I don't work on the tool above.  However, could you use procmon to identify the file which is missing? Perhaps then you could delete the containing folder that way. (http://download.sysinternals.com/files/ProcessMonitor.zip

    Ben Grover

    Microsoft

    Tuesday, August 21, 2012 8:10 PM
  • Hi Ben,
    as I wrote in the first post, I can't delete the folder nor modify the ACL or take the ownership. My guess is that the integrity level for that folder is higher than admin.

    I can write a few lines of code to delete the folder by running some code at the highest integrity level possible and lowering the IL for that folder, but:

    - I would like to understand exactly what is the official path to delete apps folder when there something goes wrong
    - some official explanation on what is happening exactly would be very appreciated

    Thanks


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele

    Tuesday, August 21, 2012 8:25 PM
  • I believe I'm having the same issue after upgrading to RTM.

    Raffaele can you please explain how you went with "re-generating the certificate", as that didn't seem to fix the issue for me?

    Thanks in advance

    EDIT: I was able to get the app to run again by generating a new test certificate from inside VS (TemporaryKey.pfx), but as soon as I associate it to the app currently in the store (and StoreKey.pfx is generated) I get the same issue :(

    • Edited by Luigi Violin Wednesday, August 22, 2012 11:05 AM
    Wednesday, August 22, 2012 9:30 AM
  • Hi Luigi,
    the first step is correct: re-generate the certificate via Visual Studio so that you can debug locally with a self-signed certificate. As fare as I can see, you've already done this.

    When you want to publish the app in the store, you should get the CN=xyz1234...  from the Store and re-generate (via Visual Studio) the certificate specifying that string (CN=...). Once you have the correct identity, the store should accept the app. The check is done right after the upload, and if you don't specify the correct store identity, the upload is rejected.

    Cheers,


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele

    Wednesday, August 22, 2012 11:49 AM
  • Thanks Raffaele, I think I'm stuck in the "re-generate (via Visual Studio) the certificate specifying that string (CN=...)" part. If I "associate" the app with the one in the store the publisher string (CN=etc..) and family name are correctly set, but the app still tries to use the same runtime folder, failing because of the permission issue.
    No option in the "Configure Certificate" dropdown seems to help - if you could guess what step(s) I'm missing that would be GREAT

    Also, I didn't mean to hijack your thread so let me re-iterate questions we'd like answered :)

    - I would like to understand exactly what is the official path to delete apps folder when there something goes wrong
    - some official explanation on what is happening exactly would be very appreciated



    Luigi Violin »» Zaam »» WP7applist »»

    Wednesday, August 22, 2012 12:18 PM
  • The step you are talking about are correct IMO.
    Here is my guess:

    • Your app already had the CN=xxx got from the store.
    • You tried to run the app with the certificate generated with the Release Preview. So Windows assigned the ACLs with the previous certificate
    • Each CN=xxx has an equivalent application folder name
    • When you rebuilt and regenerated the certificate, the name was identical but the permission not and this led to the permission problem
    • Assigning a different CN=localname to a self-signed certificate works as the folder name change but the Store needs the other CN=xxx

    Did I guess right?

    We definitely need an answer from Microsoft to understand how to delete that folder.


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele

    Wednesday, August 22, 2012 12:27 PM
  • Yes, I think you're right as that would completely explain my case... this is the good news.

    The bad news is I'm stuck and can't submit any update for this app, just run it for testing purposes. I'd love to be able to remove that folder just to check if the issue persists when it is recreated. Guess I'll give it a try...

    Thanks!


    Luigi Violin »» Zaam »» WP7applist »»

    Wednesday, August 22, 2012 12:39 PM
  • Ok, this does make sense to me and I hope someone from Microsoft will soon give an answer to my question.

    I would suggest to reboot as, as far as I could see, Windows re-check those folders during the boot phase.


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele

    Wednesday, August 22, 2012 12:50 PM
  • Bingo!

    Dual booted to Windows 7 and I was able to delete the folder right away (go figure). Back on Win8, now everything works as normal again.

    Note to self: a clean install is always the best option.

     

    Thanks a lot for the support Raf :)


    Luigi Violin »» Zaam »» WP7applist »»

    Wednesday, August 22, 2012 1:12 PM
  • Great! Glad to hear that :)

    From my side, thie issue is still *NOT* closed yet. An technical explanation is still needed from MS.


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele

    Wednesday, August 22, 2012 1:21 PM
  • Hi Raffaele and Luigi,

    Microsoft is aware of this issue and is working on a resolution.  The problem is that the directory has been marked for deletion, but there are still open handles on the directory, so it hasn’t been removed yet.  That is why rebooting appears to fix the problem; the open handles get closed which allows the deletion to complete.

    Friday, August 24, 2012 8:15 PM
    Moderator
  • Dawn M [MSFT] wrote:

    Hi Raffaele and Luigi,

    Microsoft is aware of this issue and is working on a resolution.  The problem is that the directory has been marked for deletion, but there are still open handles on the directory, so it hasn’t been removed yet.  That is why rebooting appears to fix the problem; the open handles get closed which allows the deletion to complete.

    Thank you for confirming the bug.

    Can you please give us more details about the kind of ACLs and/or ILs that are applied to package folders?
    Some background would be very appreciated.


    Raffaele Rialdi  http://www.iamraf.net
    Weblog: http://blogs.ugidotnet.org/raffaele
    Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
    UGIdotNET - http://www.ugidotnet.org/


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    Saturday, August 25, 2012 6:11 PM
  • Close the Simulator before the debug (Local Machine).
    Tuesday, October 16, 2012 5:51 PM
  • I didn't use the simulator at that time, so it can't be the solution.

    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele

    Tuesday, October 16, 2012 5:54 PM
  • FINALLY! thanks a lot. i've been looking for a solution for a while. deleting crap at \Users\*name*\AppData\Local\Packages did the trick

    i hate this app store so much. worst thing in the world  to troubleshoot

    Saturday, April 1, 2017 10:06 PM