Solved: Win 10 Test VM Loses The Ability To Run XAML

[NoelC]

I've yet to figure out why, but after a few days my up-to-date and heavily tweaked 10586 test VM somehow loses the ability to run the Settings App and the Windows Start menu.  The Start Menu I couldn't care less about, as I use Classic Shell, which continues to work, but there are things that are needed from the Settings App (like running Windows Update).

I've recovered from this several times by going back to an older 10586.104 snapshot, applying all Windows Updates, then moving forward.  I've even saved a snapshot of 10586.218 (while running) that when I restore it I can still run Settings.

Before I saved that snapshot I made sure I could reboot over and over and run Settings successfully.

But once I reboot the above, I can no longer start Settings.  After a logon that takes about 10 seconds longer than it should, when I try to start Settings, after a few second delay Explorer starts up instead, pointed to my Documents area:

Note that ApplicationFrameHost is not running.

The Windows Start Menu also does not open.

Another thing I've noticed is that when the system gets into this state where Settings won't start it seems to take longer to log in than it did when settings will work.  It's like some part of the UWP startup process is failing during logon, thus leading to Settings not being able to run.

It's not that NOTHING from the UWP can run when the system gets into this failure state...  I can open the Notifications pane.

This system has had Cortana and all other Apps removed.

It's as though something expires or becomes corrupted some days after having a working system.  This didn't happen before build 10586.164.  I don't see blocked attempts to communicate online, so I don't think it's a matter of not being able to call the mothership.

Edit:  More info:

An error is logged in the Application log when I try to run SystemSettings.exe:

Faulting application name: SystemSettings.exe, version: 10.0.10586.11, time stamp: 0x56457cb1
Faulting module name: SystemSettings.dll, version: 10.0.10586.71, time stamp: 0x5699d4ed
Exception code: 0xc0000409
Fault offset: 0x00000000000218fa
Faulting process id: 0x908
Faulting application start time: 0x01d198cc250a8566
Faulting application path: c:\Windows\ImmersiveControlPanel\SystemSettings.exe
Faulting module path: c:\Windows\ImmersiveControlPanel\SystemSettings.dll
Report Id: a93cd376-4805-415a-87a4-80b90c494e5b
Faulting package full name:
Faulting package-relative application ID:

The above is followed in about 7 seconds by this:

svchost (1952) TILEREPOSITORYS-1-5-21-1325954093-1754166717-3042824528-1001: 
The log range read from the file "C:\Users\NoelC\AppData\Local\TileDataLayer\Database\EDB.log" 
at offset 688128 (0x00000000000a8000) for 4096 (0x00001000) bytes failed verification due 
to a range checksum mismatch. The expected checksum was 0 (0x0) and the actual checksum was 
999080185957709705 (0xddd7222c223f789). The read operation will fail with error -501 (0xfffffe0b). 
If this condition persists then please restore the logfile from a previous backup.

Fellow Windows 10 tweakers: 

Can you think of anything that could cause this?  Do you have any ideas how to proceed to diagnose and fix this?  What I should look at?

-Noel

Edited April 18, 2016 by NoelC

[jaclaz]

I would try checking the integrity of the database (or restoring a previous version) before anything else. *like*:

https://answers.microsoft.com/en-us/insider/forum/insider_wintp-insider_security/critical-error-start-menu-and-cortana-arent/746d57f4-95b0-4c64-be92-2614e8c9584a?page=30&auth=1

https://community.spiceworks.com/how_to/124543-windows-10-corrupt-tile-repository

jaclaz
 

[NoelC]

Thank you, jaclaz,

Recovering a known good vedatamodel.edb file and deleting the .log files indeed resolved the problem and sped the logon back up. 

The only difficulty with this particular file is that you need to log off to be able to access it, as the Tile Data Model Service has it open whenever you're logged in.  For me that was no issue, as I could just log out and access the folder C:\Users\NoelC\AppData\Local\TileDataLayer\Database via networking.

It's possible just deleting the offending .LOG file might have been enough to fix it, I don't know.

Kudos to you for finding just the right info!

What I don't yet know is what's regularly corrupting this database (.LOG file).

I loved the comment by the poster at the second link, about the apparently problematic EDB format from Exchange being used in Windows 10 for a critical data structure:  "I was very excited to see that it was in use here."

Microsoft is prone to building on shaky foundations.  Perhaps there is a need for a "backup a good copy of the EDB so it can be restored on demand" application or script.

-Noel

Edited April 17, 2016 by NoelC

[jaclaz]

Maybe it is accessible also through (say) Unlocker:
http://www.emptyloop.com/unlocker/

or via RAW (direct) disk access (JFYI):
http://reboot.pro/topic/7400-copy-locked-system-files-tis-now-possible/
 

But the one that is "online" is anyway corrupted so one needs to use another user account or a PE or (as you did) a network connection to replace it, while if the Unlocker works on it AND deletion solves the issue it could work.

jaclaz

 

Edited April 17, 2016 by jaclaz