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: 200
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: 1512
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: 200
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: 1512
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: 1135
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: 200
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

DSperber

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

HTPC Specs: Show details
2+ Yrs TGB Veteran

#9

Post by DSperber » Tue Jun 25, 2019 4:39 pm

Space wrote:
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.
So here's a question: why is the size of MSPR.HDS always the same???

Image

I happened to be curious about whether or not my nightly backups (which of course include the updated MSPR.HDS available at the time the backups get run) were successfully capturing the up-to-date version of this file, so that in case I needed to restore it would it be usable and up-to-date. I wanted to know if it was necessary to copy/backup and/or restore only in SAFE MODE in order to ensure that the results were as expected. Or, could I just treat this as an ordinary file, even though WMC is active 24/7.

Now back some years I used to have a problem with WMC unable to get to the Ceton tuners (which are network devices, accessed through TCPIP and 192.168.200.1/2) whenever for my work I was VPN-connected to a remote customer computer, through assorted VPN software products. They all seemed to shut down some/all outside network and internet connectivity, probably in the interests of "security" and how VPN facilitated that security. So while VPN connected, I was for example not also able to check my email or browse the internet, and certainly could not be recording TV programs using the Ceton tuners. My workaround was simply to use my laptop to do this VPN-related remote work, rather than using my HTPC.

Anyway, one of the side consequences of using VPN on the HTPC was that once the VPN connection was closed, for some reason the Ceton drivers did not just bring back access and normal functionality to the Ceton tuners. I had reported this to Ceton (back years ago when they were still alive) but they were baffled, and certainly never provided any solution.

Now initially the only solution I had to this "loss of Ceton tuners after VPN" was to re-boot the machine. Obviously annoying and undesirable, but I didn't know any other way to kick-start the Ceton tuners back into a usable state, and it definitely was not happening "naturally" through any number of actions I might take to try and wake it back up.

And then I discovered a "solution", which worked successfully 99.9% of the time. Only in the rarest of circumstances was it unsuccessful, requiring me to re-boot. The "solution" was a series of two commands (which I named VPN1.bat and VPN2.bat) performed in sequence:

VPN1:

Code: Select all

taskkill /im ehrecvr.exe /f
VPN2:

Code: Select all

net start ehrecvr
%systemroot%\ehome\ehprivjob.exe /ocurdiscovery /ex
Magically, this would first STOP and then START the WMC process, and in doing so would re-establish all TCPIP network connectivity to the Ceton tuners which were "rediscovered" by the second command.

I am guessing that doing the "taskkill" for ehrecvr.exe in the VPN1 command would also CLOSE all open files, including MSPR.HDS if it were open (as it always is, presumably). Then my NovaBACKUP could definitely for sure back it up with integrity. And then after the backup completes the VPN2 command could be issued to bring back WMC, and thereby re-open MSPR.HDS, etc. Of course this would be problematic if I really was using WMC to record something in the middle of the night when NovaBACKUP kicked off. And it might actually be completely unnecessary if the file could be read/backed-up successfully even if open in WMC as it seems to be, as I really do have non-null backup versions of it taken every night by NovaBACKUP.

So I was thinking about all of this, and just investigating and poking around. And that's when I noticed that at least for this particular HTPC, the size of MSPR.HDS doesn't seem to have changed in almost two months! I'ts been 18,354,176 bytes and despite the fact that many additional copy-protected recordings have been made, this "file" does not seem to change in size over time!! Why is that? Anybody else see a similar symptom?

Now that's not always the size of MSPR.HDS, just on this particular HTPC for the past two months. I actually have two other HTPC machines (one of which hasn't been used at all in two years, and the other of which hasn't been used to do any new WMC recordings for six months although it has been up and running Win7) and their MSPR.HDS file sizes are definitely different (although I don't know yet if they, too, remained unchanged over the last month or two of their active use, but will try and investigate that).

Image

Image

Anybody have more in-depth knowledge about MSPR.HDS, why it seems to remain the same size for extended periods despite new recording data injecting into it daily?

Space

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

HTPC Specs: Show details

#10

Post by Space » Tue Jun 25, 2019 10:46 pm

The file size not changing is an interesting observation. Does the size remain the same even after a new copy protected recording is made and then the system is rebooted? It would seem to be a bad idea to not flush the buffers to the file whenever it is written to, as it would be vulnerable to a system crash/power outage.

Perhaps it allocates space to the file in blocks and only increases the file size when new blocks are needed. I know that with some databases you specify a database size at the start and it creates a file of that size, even if it is "empty". I have no idea if this is what is happening here, but it could allocate initial space and then only when the existing data fills that allocated space does it allocate more "free" space in the file. But this is all just supposition, as I am no database expert.

One thing you can do is do a binary comparison of the equal-size backup files to see if they are the same or if they are different. If you have Win7 (or perhaps Win10 as well) you can use the "FC" command to compare binary files. The output is just a list of each byte that differs in the two files:

FC /B file1 file2

Be sure to use the /B (binary) option or you may get a wall of binary characters sent to the screen.

There are also binary file compare tools with a visual interface, but I have not used them. This one seems to be free:
https://www.cjmweb.net/vbindiff/
Note that I think this still requires you to use the command line to specify the files as arguments, so it is not a true Windows GUI type program (it was ported from Linux).

Post Reply