Adventures with \Playready\MSPR.HDS and DRM

An evolving, supported alternative to Rovi
Forum rules
★ Download the latest EPG123 here: http://epg123.garyan2.net <> Setup guide here: http://epg123.garyan2.net/downloads/epg123_Guide.pdf
Post Reply
DSperber

Posts: 195
Joined: Thu Jan 16, 2014 1:35 am
Location:

HTPC Specs: Show details
2+ Yrs TGB Veteran

Adventures with \Playready\MSPR.HDS and DRM

#1

Post by DSperber » Thu Jun 06, 2019 1:12 am

It works!!! Saving/restoring MSPR.HDS (while in SAFE mode) absolutely seems to retain usability of all of the DRM copy-protected WTV recordings made by my Ceton tuner. JOY!!

For the past week or so, my HTPC has been acting up strangely. I don't know what caused it but its behavior has been deteriorating. Extender RDP sessions seem to "hang" even though I've powered the extender off, so that when I try to re-boot (hopefully to reset things back to their normal behavior) I get a message about currently still-active connections, etc. That's not the only mysteriously should-not-occur symptom, and it's all very unexpected and not right.

Not knowing what might have happened over the past week that triggered this, I decided to restore a "GOLD" system image backup I had specifically taken back on May 28, because I had just finished some software installs and updates and decided since things overall were working so blissfully well with this HTPC that it deserved to be "memorialized" in a special backup, apart and separate from my normal regular ongoing nightly "system image" backups which go back 7 generations in a continuing loop.

So first I booted to SAFE mode, in order to preserve both (a) c:\ProgramData\Microsoft\Playready\MSPR.HDS, as well as (b) my NovaStor NovaBACKUP folder also located in ProgramData which contains data on my regular nightly "data" folder/file backups. If I was going back to a Windows image from 5/28 I didn't want to lose both (a) access to DRM copy-protected recordings made right up to 4PM today, and (b) logs from NovaBACKUP run over the past 8 days. I did a simple COPY from the two source ProgramData folder locations to a "saved data" folder location on my G-drive that I had created many years ago for such use.

Then I booted to Macrium Reflect, and restored the "Gold" image of my Win7 C-partition from 5/28 (only takes 2 minutes).

Then I re-booted back to Boot Manager, and pressed F8 to get into Safe mode. I then deleted the current version of \PlayReady\MSPR.HDS as well as the NovaBACKUP log data folder, and replaced them with the latest up-to-date versions I had just a few minutes earlier preserved on my G-drive from my pre-restore latest Windows.

Then I re-booted normally, got into WMC and verified that I could in fact still play those DRM copy-protected recordings made from just today, before 4PM. AMAZING!!! It works! Thumbnails correctly appear in the recordings list, and the programs themselves play normally..

So, thanks again for this insight regarding MSPR.HDS holding all of the DRM keys. Properly preserving/restoring in SAFE mode guarantees that even an older "system image" backup must be restored, at least 100% of the DRM copy-protected recordings will still be playable after the restore, even though the recordings were made more recently than the date of the "system image" backup that got restored.

Now let's hope that whatever was the cause of the "instability" in my HTPC that seemed to have crept in over the past week or so will no longer be present now that I've restored my GOLD backup from 5/28. I know things were "perfect" back then so much so that I was inspired to take this "GOLD" image. So let's hope that's true now as well, having restored that image.

Space

Posts: 1503
Joined: Sun Jun 02, 2013 9:44 pm
Location:

HTPC Specs: Show details

#2

Post by Space » Thu Jun 06, 2019 1:55 am

Good to see further confirmation of what others have reported. I have not had to do this type of restore myself, but it is reassuring that if I needed to, I know how to do it and that it will work.

DSperber

Posts: 195
Joined: Thu Jan 16, 2014 1:35 am
Location:

HTPC Specs: Show details
2+ Yrs TGB Veteran

#3

Post by DSperber » Thu Jun 06, 2019 4:47 am

I did check my regular nightly "data" folder/file "incremental" backups (which archive anything created or changed in the past 24-hours), and sure enough c:\ProgramData\Microsoft\Playready\MSPR.HDS is always present on each night's archive. What I don't know is whether or not the backup taken at 1AM every night will successfully copy it (even if it is "open" and/or conceptually "in use"by WMC),. I'm trying to decide if I MUST actually have to be in SAFE mode to know that I'm getting a 100% usable preserved version of that file.

There's certainly no warning or other message from NovaBACKUP regarding "file in use" or giving me any reason to suspect that it might not be the current active version, but an older "original" starting version. I suppose whatever's on disk is what gets backed up, not what might be in-memory and newer. So if the file is written out by WMC whenever a new program gets recorded (which seems very likely and plausible and reasonable), and as long as the file is not "in-use" and thus prevented from being read by NovaBACKUP, I would have a hunch that the regular nightly backup would be usable for restoring from (as long as there weren't yet more additional copy-protected recordings made after that backup was taken, which would thus definitely be "lost" following the back-dated image restore).

Certainly doing the preserve/restore in SAFE mode right before and after the image restore is the absolute most reliable way to ensure no copy-protected recordings would get lost. But I suppose in absolute worst case last night's 1AM backup version could be considered an emergency fallback, with a possible "price" if later newer DRM recordings also exist.

Space

Posts: 1503
Joined: Sun Jun 02, 2013 9:44 pm
Location:

HTPC Specs: Show details

#4

Post by Space » Thu Jun 06, 2019 5:25 am

Yeah, I remember some discussion about the file being in use when copying it, but I don't remember if there was any verdict on if it was safe or not. I seem to recall that if you can copy it without error, it should be good, but don't quote me on that.

Also, when restoring it, I think you can stop one of the services, restore the file and then start the service again instead of doing it in safe mode, but again, I don't remember the details, and since this should be a rare occurrence, doing it in safe mode should not be a big deal.

Sammy2

Posts: 1644
Joined: Fri Aug 24, 2012 7:35 pm
Location:

HTPC Specs: Show details

#5

Post by Sammy2 » Thu Jun 06, 2019 2:56 pm

I do not miss messing with DRM one bit.

jachin99

Posts: 1132
Joined: Wed Feb 24, 2016 3:36 pm
Location:

HTPC Specs: Show details

#6

Post by jachin99 » Thu Jun 06, 2019 3:51 pm

Now I wonder if there is some way you could restore that image & key to a new PC build. I know new hardware would probably require updated drivers but I wonder if you could restore the old image to the new hardware and have drivers work well enough to run everything smoothly.

cwinfield

Posts: 552
Joined: Tue Feb 12, 2013 1:14 am
Location: Monroe, NC

HTPC Specs: Show details

#7

Post by cwinfield » Thu Jun 06, 2019 4:25 pm

jachin99 wrote:
Thu Jun 06, 2019 3:51 pm
Now I wonder if there is some way you could restore that image & key to a new PC build. I know new hardware would probably require updated drivers but I wonder if you could restore the old image to the new hardware and have drivers work well enough to run everything smoothly.
Nope, the mspr.hds file is tied to your hard drive partition data and windows install, this generates the encryption key that identifies that unique computer for digital rights management.

If you had identical hardware you could use a restore image and it may work...

DSperber

Posts: 195
Joined: Thu Jan 16, 2014 1:35 am
Location:

HTPC Specs: Show details
2+ Yrs TGB Veteran

#8

Post by DSperber » Sat Jun 08, 2019 7:13 am

Ok. The story of which originally prompted me to start this thread regarded a major malfunction:

"For the past week or so, my HTPC has been acting up strangely. I don't know what caused it but its behavior has been deteriorating. Extender RDP sessions seem to "hang" even though I've powered the extender off, so that when I try to re-boot (hopefully to reset things back to their normal behavior) I get a message about currently still-active connections, etc. That's not the only mysteriously should-not-occur symptom, and it's all very unexpected and not right."

So for a week or so I've been unable to start/stop and then re-start extender sessions. And that also means I've been unable to be watching a program with the extender set to 1080i, and then get into settings (which stops the session) to reset to 720p, and then re-start the extender to now watch a new program at 720p. Any "stop" of the first extender RDP session leaves the session "dangling and hung", and not stopped at all.

From a Windows internal perspective this corresponds to a 115 Event Log entry when the session starts, but no corresponding 117 entry when the session ends.

And this is why I thought something in my Windows had gotten corrupted, with the easiest way to recover being to restore the May 28 "Gold" image backup I'd taken, and then reinsert the latest MSPR.HDS prior to the restore.

Well, after a frantic week of trying lots of things which should have had beneficial effect but surprisingly had no success, I finally decided that I might need to rebuild this failing HTPC again (but salvaging current copy-protected recordings by use of the MSPR.HDS trick), and to give me the opportunity to do this I decided to re-activate my second "currently spare" and turn it into my "production" machine. So I went to the machine, and before doing anything just wanted to confirm that it still "worked perfectly" and didn't exhibit this mysterious "dangling extender RDP session" symptom I've been fighting. Imagine my surprise to discover that even this second HTPC, which hadn't been used for months, was also exhibiting the exact same "dangling extender RDP session" symptom!!

How can this be? Only some common hardware or common software with the other failing HTPC exhibiting the same anomaly. I do have a spare router, and decided that as inexplicable as it sounded I suppose I could try replacing my current main router with this spare... just to be sure it wasn't somehow part of the story. But before spending any time on that activity I decided to back out the current nVidia 430.86 driver I'd recently updated to. Not surprisingly, that had no effect.

Also, something was clearly seriously wrong, as QWINSTA and RWINSTA commands were not accomplishing the manually forced "kill" termination of an open active RDP session.

Image

I then decided to act on my real main suspicion, which was some harmful effect of this past week's "product feature enhancement" of BitDefender 2019 Total Security. You may remember that back around four months ago I had discovered a software conflict between Malwarebytes and Macrium Reflect, which had been responsible for the "freeze" symptom I'd been fighting on both of my HTPC machines for eight months. Until the software conflict was resolved (by a fix from Macrium Reflect) I uninstalled Microsoft Security Essentials and Malwarebytes and instead went to BitDefender as my anti-virus product. Of course this "fixed" the freeze problem (since Malwarebytes was no longer on my system, and thus could no longer bump heads with Macrium Reflect) so I've been running with BitDefender ever since.

Because of the curious recent timing of my symptom's birth, along with the recent release of a significant feature update to BitDefender, I decided on a flyer to temporarily disable (but not fully uninstall) BitDefender, just to see if that cured the RDP session problem. It did not.

I then decided that just to be absolutely positive, I would fully uninstall BitDefender and reinstall Microsoft Security Essentials. Amazingly... THIS FIXED IT!!! Sure enough, extender sessions were now correctly ending with power-off as they should and as they always have until this past week. I then went to my second HTPC (where the same symptom had surprisingly also been occurring) and repeated my "cure": uninstall BitDefender and reinstall MSE. And sure enough, once again THIS FIXED IT!!!

So that's how I'm still running at the moment. I've obviously reported the issue to BitDefender, and haven't yet reinstalled Malwarebytes (only because I canceled my Malwarebytes licenses when I purchased BitDefender a few months back) but will make a decision on that soon. I plan to make one of my machines available to BitDefender as a "lab rat" so that we can reproduce the failure and through their diagnostic trace code chase down what is going wrong and then test out the proposed "fix".

Note that there not only was this extender RDP session problem I was observing this past week. There were several other graphics and audio and memory and CPU anomalies I had noticed, and these too have all disappeared with the uninstall of BitDefender. These may or may not be tied to the same new product features responsible for the extender RDP session issue, but for sure were clearly tied to the presence of the current version of BitDefender and are gone now that BitDefender is uninstalled.

I'm now going to make a new "Gold" version as of right now... absent BitDefender and including MSE.

The happy ending is that it turns out I do NOT have to do anything additional to both of my HTPC's to get them back to "normal". There is no hardware issue, no WMC or extender-related software issue, no Windows corruption. It was BitDefender's recent product enhancement which was 100% the culprit.

Happy ending, thankfully. Paired 115/117 events are once again occurring. Now I can get some sleep again.

Image

Post Reply