Sunday, March 1, 2015

Not Exactly Charming

I've been annoyed with charms menu.  Most of the time, it extends in front of legitimate controls I am trying to click in my browser, evoking the "I'm TRYING to $@#!ing work here!" response from me.

A month ago, I found windows.immersiveshell.serviceprovider.dll in Process Explorer, and wondered if this had to do with the Charms bar.  I looked it up, and found an article that describes steps to use SysInternals' Process Explorer to terminate the thread that is running code within this "Immersive Experience" library.  In closing, the author states that using Process Explorer is not automatic (it entails user interaction), and that s/he hopes someone finds an effective way to disable the immersive start menu.

I found another article suggesting that the Registry affords this functionality.  I tested it, finding that it indeed does.  The relevant registry keys are:


I also think that following the advice I found of right-clicking the taskbar to arrive at Properties and selecting the Navigation tab may have helped me locate a control to add another registry entry that has reduced the annoyance factor of the Windows 8 UI.  The relevant registry key was:


A command script for making all these changes at the same time follows:

REG ADD HKCU\Software\Microsoft\Windows\CurrentVersion\ImmersiveShell\EdgeUi /v DisableTRCorner /d 1 /f
REG ADD HKCU\Software\Microsoft\Windows\CurrentVersion\ImmersiveShell\EdgeUi /v DisableTLCorner /d 1 /f
REG ADD HKCU\Software\Microsoft\Windows\CurrentVersion\ImmersiveShell\EdgeUi /v DisableCharmsHint /d 1 /f

Nevertheless, I thought I'd see if I could implement something similar to the "Kill Thread" function in SysInternals' process explorer.  The result can be found here on my Github:

It is based on the following two articles:
What didn't initially occur to me was that there is no API for enumerating threads associated with a particular module.  There is, however, the fact that a thread has a start address property that indicates what code was first executed when the thread was started.  As long as no indirection is incorporated (such as a dispatch function that uses arguments to determine what code is subsequently executed), and no tampering has been undertaken by the target process for any reason such as obfuscation (not sure if this structure is in the PEB or kernel), it is possible to classify a thread as being associated with a particular library by assessing whether the thread's start address lies within the base and end address of that library.  So, that's what I did.  Thanks, Rohitab!  See the code for more details.

The end result was a program that is capable of locating and terminating the thread that handles Immersive Experience events such as the charms menu.  Alas, that thread also handles things like wireless network configuration and the start menu which I commonly use to invoke programs whose locations I do not know, such as the Windows SDK prompt.  So, I would recommend trying the registry maneuvers first, restarting explorer to evaluate.  Regardless, the source code for the project I created could still be useful in the general sense for terminating specific threads in arbitrary processes.  Not sure I can think of an example, but nonetheless, it's out there, just in case ;-)

No comments:

Post a Comment