Hello,

This is driving my insane. Windows Store decided that it no longer opens when I click on it. I have been researching this issue for two days in a row now so far I got no solution.

What I did managed to narrow down to is that if I call the windows store using the command prompt 'start' command, I get a "remote procedure call" error (the the one in point 2 below).

Here is what I have tried:

0. Tried running Appsdiagnostic cabined did not fix any issues. It does try to run WSRESET.EXE but it gives me an error (see point 2 below).

1. Creating a new account - Same issue.

2. Run WSRESET.EXE - Gives me the error: The remote procedure call failed.

• Yes. all RPC services are running as expected.
• Permissions of HKCU\Software\Classes\[...]\AppModel\Repository\Packages seems fine (owner: SYSTEM). Anyway, any attempts of change gives me an access denied error.

3. Tried running SFC - No joy

4. Tried running DISM with /RestoreHeath - No joy.

5. Tried running SFCFIX - Here is what I got:

AutoAnalysis::
CORRUPT: C:\Windows\winsxs\amd64_microsoft-windows-store-client-ui_31bf3856ad364e35_6.3.9600.17669_none_a935f262375dc12f\WinStoreUI.dll
CORRUPT: C:\Windows\winsxs\amd64_microsoft-windows-u..ed-telemetry-client_31bf3856ad364e35_6.3.9600.17747_none_90df8130dac08ee0\utc.app.json
CORRUPT: C:\Windows\winsxs\amd64_microsoft-windows-u..ed-telemetry-client_31bf3856ad364e35_6.3.9600.17747_none_90df8130dac08ee0\telemetry.ASM-WindowsDefault.json

6. Tried re-registering the Store app by running: powershell -ExecutionPolicy Unrestricted Add-AppxPackage -DisableDevelopmentMode -Register $Env:SystemRoot\WinStore\AppxManifest.xml

7. Tried the instructions found here to fix the remote procedure call error.

NOTE: System restore or refresh are NOT an option.

I'm impressed by the poor quality of the Modern/Metro apps. this looks more like pre-Alpha build quality than anything else.

I don't know what to do. Could someone please advise?

Regards,
P.

• Edited by pmdci Thursday, May 14, 2015 9:30 PM added point 7

Hi Robert,

I am new to procmon. So what I did first was to filter all entries as to show only entries that contains the word winstore in the path. So every time I try to open the Store app, I can see the relevant entries.

Then when you mentioned WinStoreUI.dll I decided to remove the winstore filter and replace it with 'WinStoreUI'. However when I open the Store app, nothing shows on procmon when the WinStoreUI filter is in place.

If you have any suggestions on how to run procmon to look for clues, please let me know.

I tried running sxstrace. I generated a trace file but when I parse it to a txt. I get a 3 bytes txt file with nothing in it...

Regards,

P.

• Edited by pmdci Monday, May 04, 2015 2:29 PM rant

CORRUPT: C:\Windows\winsxs\amd64_microsoft-windows-store-client-ui_31bf3856ad364e35_6.3.9600.17669_none_a935f262375dc12f\WinStoreUI.dll
CORRUPT: C:\Windows\winsxs\amd64_microsoft-windows-u..ed-telemetry-client_31bf3856ad364e35_6.3.9600.17747_none_90df8130dac08ee0\utc.app.json
CORRUPT: C:\Windows\winsxs\amd64_microsoft-windows-u..ed-telemetry-client_31bf3856ad364e35_6.3.9600.17747_none_90df8130dac08ee0\telemetry.ASM-WindowsDefault.json

The two .json files is normal to show up after SFC per: https://support.microsoft.com/en-us/kb/3022345?wa=wsignin1.0

However for CORRUPT: C:\Windows\winsxs\amd64_microsoft-windows-store-client-ui_31bf3856ad364e35_6.3.9600.17669_none_a935f262375dc12f\WinStoreUI.dll

I would start with repairing what was corrupt by replacing it with a known good copy if you haven't already tried?

I'm also assuming you've tried this already:

Open RegEdit

Go to HKCU\Software\Classes\LocalSettings\Software\Microsoft\Windows\CurrentVersion\AppModel\Repository\Packages

• Right click the key and select Permissions
• Check if the Owner is SYSTEM. If not, change the Owner to SYSTEM.

• Edited by aw00t Tuesday, June 16, 2015 2:26 AM

CORRUPT: C:\Windows\winsxs\amd64_microsoft-windows-store-client-ui_31bf3856ad364e35_6.3.9600.17669_none_a935f262375dc12f\WinStoreUI.dll

When I try to run the app, it logs 3 entries in the Event Viewer application log:

1. Level: Error | Source: Application Error | Event ID: 1000 | Task Category: (100)
2. Level: Information | Source: Windows Error Reporting | Event ID: 1001 | Task Category: None
3. Level: Error | Source: Apps | Event ID: 5973 | Task Category: (5973)

Here are the details of each entry:

1. Application Error:

Faulting application name: WWAHost.exe, version: 6.3.9600.17415, time stamp: 0x545036ce
Faulting module name: KERNELBASE.dll, version: 6.3.9600.17415, time stamp: 0x54505737
Exception code: 0x00000004
Fault offset: 0x0000000000008b9c
Faulting process id: 0xa08
Faulting application start time: 0x01d0a87f67e49c37
Faulting application path: C:\Windows\System32\WWAHost.exe
Faulting module path: C:\Windows\system32\KERNELBASE.dll
Report Id: a5a5b2e4-1472-11e5-bffc-88532e7dc714
Faulting package full name: winstore_1.0.0.0_neutral_neutral_cw5n1h2txyewy
Faulting package-relative application ID: Windows.Store

2. Windows Error Reporting:

Fault bucket 98886692228, type 5
Event Name: MoAppCrash
Response: Not available
Cab Id: 0

Problem signature:
P1: winstore_1.0.0.0_neutral_neutral_cw5n1h2txyewy
P2: praid:Windows.Store
P3: 6.3.9600.17415
P4: 545036ce
P5: KERNELBASE.dll
P6: 6.3.9600.17415
P7: 54505737
P8: 00000004
P9: 0000000000008b9c
P10: 

Attached files:
C:\Users\MyUserAccountDirectory\AppData\Local\Temp\WER7C61.tmp.WERInternalMetadata.xml

These files may be available here:
C:\Users\MyUserAccountDirectory\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_winstore_1.0.0.0_d1f803401aaa12efca47e9c0e64e3578bee41d_71dd0148_25b07f30

Analysis symbol: 
Rechecking for solution: 0
Report Id: a5a5b2e4-1472-11e5-bffc-88532e7dc714
Report Status: 0
Hashed bucket: f3387ff7711554c02df0234bef4c025f

3. Apps:

Activation of app winstore_cw5n1h2txyewy!Windows.Store failed with error: The remote procedure call failed. See the Microsoft-Windows-TWinUI/Operational log for additional information.

4. Contents of Report.WER
Found at: C:\Users\MyUserAccountDirectory\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_winstore_1.0.0.0_d1f803401aaa12efca47e9c0e64e3578bee41d_71dd0148_25b07f30

• Edited by pmdci Tuesday, June 16, 2015 10:10 PM

Nope. NOTHING

Here are the news, though:

1. SFC no longer points to a corruption. Everything seems ok.

2. Store still crashes when trying to run it.

3. I noticed that it logs errors in the event viewer. These seem to provide more useful information about the crash than anything else.

I have to say that this issue takes my faith away from "modern apps". They are a pain to troubleshoot. Adding to the fact that you cannot specify where you want modern apps to be installed, and the fact that they are slower than their counterparts, really puts me off from using them. I will always prefer a desktop app than modern ones.

Not a solution, but a workaround: I will wait for the Windows 10 upgrade, which I am "99.9%" [excuse the fake stats] that it will resolve the issue.

I am fully aware that the suggestion of such "solution" would infuriate most users -- and righteously so.

I think we're on to something here, Robert. This is the results of fsutil when I run it on my work laptop:

Is there a way that I can update the link to the correct file?

I think this was me copying the contents of my wife's c:\windows\WinStore\ folder into my laptop for troubleshooting purposes. But like you said it was indeed crashing before.

Is there a way that I can update the link to the correct file?

Supposedly fsutil hardlink has a create option but I have never seen it being used.  I thought that sfc is what would have repaired problems.

Did the svc /verifyfile=  show anything?  Note that so far I have only been suggesting diagnostics, not repairs but there is also  sfc  /scanfile=  which supposedly uses the same syntax.

I'm not sure how we know what is real.  I found a description of how I think it is supposed to work

http://blogs.technet.com/b/joscon/archive/2010/08/06/should-you-delete-files-in-the-winsxs-directory-and-what-s-the-deal-with-vss.aspx

(BING search for
    fsutil hardlink create winsxs
)

I don't understand how it could "operate properly" if the real thing was deleted, so maybe I am missing something but this is an experiment that I don't want to try even on my VM.  E.g. I would have thought that deleting the copy in WinSxS would also result in the link to it in Winstore going at the same time.

So, do you have the WinSxS copy in the problem system?  If not perhaps it would be better to rename the Winstore one to that name and then do an fsutil hardlink create.  Who knows?

I can't remember if I gave you my way of getting an inventory of modules and lengths (not versions or dates because I have found that they are not maintained consistently)...  Looks like we did that already and things looked OK.  Beats me.  And again, for all I know it may be a red herring.

Goo

1. SFC no longer points to a corruption. Everything seems ok.

2. Store still crashes when trying to run it.

3. I noticed that it logs errors in the event viewer. These seem to provide more useful information about the crash than anything else.

But is it the same crash or something different, e.g. in view of the fact that your Winstore.dll corruption has been fixed.  BTW does that include the fsutil result?

FWIW the only new idea I got from looking at the diagnostics again is where uxtheme.dll was loaded.  If that happened last, e.g. if the number means anything about the order that modules are loaded in it could be pointing to it as a problem area.  Then one example of known causes of crashes and other strange symptoms in that area are third-party customization of system modules.  So if you have anything like that installed try getting rid of it temporarily as a test.

BTW I only now have become aware of the Event category MoAppCrash.  Sorry I overlooked that before.  I imagine it could be used for a different diagnostic tack.  Then also, something else that I subsequently have learned about, is that supposedly we can invoke a plethora of tracing as specified by netsh trace show providers | sort /+40 | clip  (to capture them sorted by provider name from a cmd window).  Ironically the word Modern does not appear in that list but the strings UI App and Theme are all there multiple times.

HTH

When I try to run the app, it logs 3 entries in the Event Viewer application log:

1. Level: Error | Source: Application Error | Event ID: 1000 | Task Category: (100)
2. Level: Information | Source: Windows Error Reporting | Event ID: 1001 | Task Category: None
3. Level: Error | Source: Apps | Event ID: 5973 | Task Category: (5973)

Here are the details of each entry:

1. Application Error:

Faulting application name: WWAHost.exe, version: 6.3.9600.17415, time stamp: 0x545036ce
Faulting module name: KERNELBASE.dll, version: 6.3.9600.17415, time stamp: 0x54505737
Exception code: 0x00000004
Fault offset: 0x0000000000008b9c
Faulting process id: 0xa08
Faulting application start time: 0x01d0a87f67e49c37
Faulting application path: C:\Windows\System32\WWAHost.exe
Faulting module path: C:\Windows\system32\KERNELBASE.dll
Report Id: a5a5b2e4-1472-11e5-bffc-88532e7dc714
Faulting package full name: winstore_1.0.0.0_neutral_neutral_cw5n1h2txyewy
Faulting package-relative application ID: Windows.Store

2. Windows Error Reporting:

Fault bucket 98886692228, type 5
Event Name: MoAppCrash
Response: Not available
Cab Id: 0

Problem signature:
P1: winstore_1.0.0.0_neutral_neutral_cw5n1h2txyewy
P2: praid:Windows.Store
P3: 6.3.9600.17415
P4: 545036ce
P5: KERNELBASE.dll
P6: 6.3.9600.17415
P7: 54505737
P8: 00000004
P9: 0000000000008b9c
P10: 

Attached files:
C:\Users\MyUserAccountDirectory\AppData\Local\Temp\WER7C61.tmp.WERInternalMetadata.xml

These files may be available here:
C:\Users\MyUserAccountDirectory\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_winstore_1.0.0.0_d1f803401aaa12efca47e9c0e64e3578bee41d_71dd0148_25b07f30

Analysis symbol: 
Rechecking for solution: 0
Report Id: a5a5b2e4-1472-11e5-bffc-88532e7dc714
Report Status: 0
Hashed bucket: f3387ff7711554c02df0234bef4c025f

3. Apps:

Activation of app winstore_cw5n1h2txyewy!Windows.Store failed with error: The remote procedure call failed. See the Microsoft-Windows-TWinUI/Operational log for additional information.

4. Contents of Report.WER
Found at: C:\Users\MyUserAccountDirectory\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_winstore_1.0.0.0_d1f803401aaa12efca47e9c0e64e3578bee41d_71dd0148_25b07f30

• Edited by pmdci 9 hours 3 minutes ago

Hi Robert,

Actually according to the WER (Windows Error Reporting) file the last module to run before the app crashes is actxprxy.dll -- not uxtheme.dll (which is the second last).

There more I try to troubleshoot these so called "modern apps", the more I find them to be a laughing stock.

Mine returns the file itself...

the last module to run before the app crashes is actxprxy.dll -- not uxtheme.dll (which is the second last).

Does ProcMon actually show that?  So same idea, a corrupted module calls another module and a crash occurs.

Mine returns the file itself...

which I think is wrong but don't know why it would cause a problem.

Perhaps  sfc /verifyfile=winstoreui.dll  would show you something about that, either in the CBS.log or via ProcMon.

FWIW I just did it on my W10 VM (had to specify the full path) and as expected there were more instances of the WinSxS reference than of the  WinStore one in ProcMon.  One surprise though is that (using the Path Contains WinStoreUI filter and Count occurrences...) there were also more instances of a thing I had never seen before

Here's the equivalent in W8.1.2

C:\Windows\WinSxS\amd64_microsoft-windows-store-client-ui_31bf3856ad364e35_6.3.9600.17669_none_a935f262375dc12f\WinStoreUI-ppdlic.xrm-ms

WTH is that?  Oh.  It's some XML, so more conveniently viewed in IE.

CORRUPT: C:\Windows\winsxs\amd64_microsoft-windows-store-client-ui_31bf3856ad364e35_6.3.9600.17669_none_a935f262375dc12f\WinStoreUI.dll

OMG.  I just noticed that that is what my fsutil result is pointin

I'm a bit confused if that was sarcasm or not.