[DISCUSSION] Patch WMC to run on Windows 10 final & possible alternatives

good news, my computer just updated patches and WMC is still functional.

 

You need to login to view this posts content.

 

Remote control digits keys are suddently not working

I don't think it's related to v10 or v11 installers but since one week Media Center interprets digit keys as characters keys. I cannot change channel with remote, and search fields in Media Center shows keyboard letters when I press a digit button.

1 is &, 2 is é, 3 is ", 4 is ', 5 is (, and so on.

The same remote control installed on another computer works well. Uninstalling Media Center v11 and HID/eHome receiver drivers didn't fix the problem.

 

You can use eventwghost to see if the commands are received wrongly or are received correctly but interpreted wrongly by WMC (in the worst case you can use it to fix the problem)

 

Yes looks like V11 fixed the DISM related problems, introduced by V10.

 

great stuff thanks all

 

You need to login to view this posts content.

 

Hi,

Is there an alternative way to ensure that scheduled recordings work without having to add the network service to the administrators group?

I'm asking because this particular workaround has very bad side effects when it comes to security: network service (as its name indicates) is the user unprivileged network-facing services run as. If it's added to the administrators group, privilege escalation becomes extremely easy (just compromise one of the services and you're done). It would be great if there was another way.

Has anyone tried to determine precisely which operation is failing because of insufficient privileges? I've started investigating and so far I noticed that the StartRecording scheduled task does not have any triggers set even if a recording is scheduled, which seems wrong. I've tried using Process Monitor to look for access denied errors but no success so far.

 

I didn't investigate further but I think that either running the WMC tasks as administrator instead of network service should work.

another way could be adding the network service users to the folders and registry branches involved

mainly

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Media Center

The \windows\ehome and \program data\microsoft\ehome directories


Polsedit could be also used to fine tailor the permissions of network service.

All in all is not an impossible mission, just some patience and much time is needed to narrow exactly the missing permission that affects WMC on W10

 

You need to login to view this posts content.

 

I was thinking about changing the location of Recorded TV from Public to Users/Me, or maybe even Root. Haven't tried it yet. Does anybody think this might work?

 

Early versions of Windows 10 "ProfessionalWMC" edition couldn't start a recording either. It seems that some changes were made in Network Service scope of permission that prevent that account to do some action.

Two months ago I could start a recording by setting local administrator account as logon account for ehSched service. Exactly what T-S just said but without changing any other permission in folders or registry.

 

Good advice!

 

Indeed what I meant was use the service as administrator OR try to change the permissions on folders/registry . It wasn't an AND

 

You need to login to view this posts content.

 

EventGhost shows MceRemote.Numpad1, MceRemote.Numpad2, MceRemote.Numpad3, and so on, on both computers.

I noticed another issue on the computer where the remote digit keys don't work: when I press the green button, WMC is opened but it stays in the background; it isn't focused, the taskbar is visible, and it doesn't receive any keyboard/remote inputs. I have to click on Media Center interface in order to make remote/keyboard working.

 

~

So the problem isn't there

I saw that behavior many times even on the old XP MCE, I never understood why that sometimes happen.

Anyway the workaround is easy there is a native command to switch WMC from windows to FS. I use eventghost to bind that command to a remote button. Then, if I face the problem, I push that button twice and WMC goes from background FS to foreground windows, then foreground FS

To be sure, that command can be used on the normal powerup function, to forget the problem forever.

Outside the proper MCE plugin EG ha also its own function to put any windows in foreground, I never used it, but I'm sure it works as well.

 

Hi all,

Maybe a silly question but is it somehow possible to backup the files that contain the channels, scheduled recordings, favorite lists ?
Like for everyone update 1511 removed mce again so now that i have it back as it should be i would like to backup those settings (if possible) so that, if it ever happends again i can restore them.

 

I am pleased to announce that I discovered what I think prevents WMC from scheduling recordings.

Further investigation confirmed that the problem was indeed with the scheduled task itself - if the ehSched service is running as a privileged user such as SYSTEM, Process Monitor shows that ehSched.exe loads taskschd.dll (the task scheduler API) and then the task scheduler service successfully changes the StartRecording task. However, if it is not running as a privileged user (such as Network Service), Process Monitor still shows taskschd.dll being loaded, but the task is not changed - that strongly suggests the Task Scheduler is refusing ehSched's requests for task changes, presumably because of permission issues.

Digging further, the root cause seems to be that the method the v11 installer uses to set ACLs for scheduled tasks doesn't seem to work. What the packaged installer does is, it simply sets ACLs on "System32\Tasks\Microsoft\Windows\Media Center" that allows changes by the network service (see the "WMC64\bin\Acl" file). It also sets some other ACLs on specific tasks, and in particular sets the Network Service as "owner" of the StartRecording task. Unfortunately, that does not seem to achieve the intended effect.

After further investigation, I determined that Task Scheduler seems to ignore ACLs on files in that directory completely, even after a reboot. I believe this has something to do with the contents of "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\Microsoft\Windows\Media Center". Specifically, these registry keys contain a value named "SD", which seems to stand for "Security Descriptor". Presumably this is used by the task scheduler to authorize task modification attempts (as opposed to using the ACLs on the task files themselves).

With that in mind, I believe what's happening is:

1. The installer creates the scheduled tasks.
2. The task scheduler stores a copy of the security descriptor (which, at this point, does not have any extended permissions).
3. The installer sets ACLs on the task files, but at this point it's too late - the task scheduler already copied them.

Despite the fact that these entries are stored under the name "TaskCache", there doesn't seem to be any way of regenerating the cache to force the Task Scheduler to re-read the security descriptor from the files: if I delete the tasks from the registry, or even if I just remove the "SD" value, the task just disappears from the task scheduler.

I also tried to trick the task scheduler by creating the parent "Media Center" file folder first, then setting proper ACLs on it (hoping that newly created tasks would inherit them), and then creating the tasks. Unfortunately, that doesn't work either, because the Task Scheduler complains if we create its folders behind its back.

Fortunately, I have found an alternative solution: the Task Scheduler XML schema includes a SecurityDescriptor field that can be used to specify the ACL in the XML file. Deducing the correct SDDL string from the contents of the "WMC64\bin\Acl" file and setting them in the Tasks XML files seem to do the trick. Here's the change I made to "WMC64\bin\Tasks\StartRecording.xml":

Code:

<Task xmlns="...">
  <RegistrationInfo>
    <URI>Microsoft\Windows\Media Center\StartRecording</URI>
    <Date>1982-01-15T16:30:00-08:00</Date>
    <Source>$(@%systemRoot%\ehome\ehres.dll,-126)</Source>
    <SecurityDescriptor>D:AI(A;;0x1701ff;;;NS)(A;;FA;;;BA)(A;;FA;;;SY)</SecurityDescriptor>
  </RegistrationInfo>
  ...
</Task>

For those not familiar with Security Descriptor Strings, the descriptor above means "inherit; grant most permissions to the network service; grant full permissions to administrators; grant full permissions to system". I tried to link to the MSDN reference for this but the forum doesn't allow me to post any links

I was about to do the same for the other tasks, but then I noticed that most of them already have security descriptors - I only had to do the above for two tasks: mcupdate_scheduled and StartRecording. Looking at the ACL file, I think I understand why: it's because these are the only two tasks that don't have special ACLs - they simply rely on ACLs inherited from the "Media Center" folder, but as I mentioned above that doesn't work. If we explicitly define ACLs for these tasks in XML, everything works perfectly.

I would recommend making these changes to the XML files for these two tasks in the next version of the package. We can then get rid of the workaround.

 

Delphiwizard search for this google Seans_WMC_Backup