If so, try this simple test.
So I’ve been struggling with Windows 10 for a bunch of reasons, but the big one at the minute is that my start menu just stops opening. Along with that, the notifications pop-out and Cortana.
The biggest giveaway for me that a rogue process is at fault is that in safe mode its fine, and usually the first 5 to 10 minutes.
I got so frustrated that I opened task manager and started killing processes a few at a time and trying the start menu, including all but the key Windows ones and nVidia (because the last thing I need are MORE TDR errors…). Through this, I identified that the culprit is the “Runtime Broker” process.
Killed it, and the start menu, Cortana, notifications work again.
For at least 10 more minutes anyway.
In a tweet to me, Microsoft support say that the task involves the permissions for Metro-style apps. There’s probably a further root cause app at fault. But at least I can mitigate for now!
TLDR; try killing the “Runtime Broker” process.
So I took an old laptop I used at university – about 5 or 6 years old but a good model in it’s day, a Dell Latitude E5510 – and decided to use it as a quick ‘test’ run of the Windows 10 upgrade since it hasn’t anything too important and my main PC is being stubborn over actually offering the update.
Unfortunately, it didn’t go so well really. Thought I’d write up a quick post about a 0xC000000F blue screen error that ended up happening.
I’m about to do a particular repair so will see if it works, but I’ve surmised that the issue is that the default Dell partition table looks like this:
– DellUtility (~40 MB)
– RECOVERY (~8 GB) (Marked as boot)
– OS (~130 GB)
What seems to have occurred is that the actual install proceeded reasonably well, I can see the signs of it being completed such as the presence of the “Windows.old” folder etc. However, what Windows 10 decided to do to facilitate the install is that it saw the boot partition and hijacked its boot to use as its boot sequence.
For some unknown reason, in so doing, it increased the “RECOVERY” partition size by 1 sector – encroaching into the “OS” partition and wrecking its MBR and boot sector. This left many tools, including Windows 10, unable to ascertain the structure of the drive as NTFS. Chkdsk understands the corruption but does not resolve the partition table overlap.
I’m going to manually adjust the recovery partition down and try to repair the MBR from its backup. Let’s see how that goes.
Microsoft – partition management: 0 out of 10 for wrecking my MBR!