From Cork to Toronto

This afternoon I helped someone recover an unsaved document from an .ASD file after a crash which did not trigger the usual file recovery pane. While the File/Options/Save dialog pointed to %appdata%\Microsoft\Word , File, Open, Recent, Recover Unsaved Documents points to %localappdata%\Microsoft\Office\UnsavedFiles After copying the .ASD file into the latter (UnsavedFiles) folder, I was able to successfully open the .ASD file, save it to a DOCX and turn it over to the person I was helping. The person I was helping was using Word 2010 but I had the .ASD emailed to me, and did the recovery in Office 365 v1904, as I didn't have control of their machine.

Had a laptop come in where it would appear to boot normally, but at the logon screen both internal and external keyboards and mice did not respond. In Windows Repair, everything worked fine, just not within the operating system itself. The machine had a locally managed encrypted SSD which I wanted to decrypt before reimaging it, and there were some other items which would be more easily remediated if I could get 1-2 working login sessions before dropping the hammer on it. It did have working networking, so I gathered info via Event Viewer and established that I had access to the admin share and could control the machine via psexec. Using psexec to start SFC did not resolve the issue, nor did CBS.log point me in the right direction. The Event Viewer log for System noted a bunch of driver start events (Application Popup Event ID 26, Kernel-PnP Event ID 219) including for mouhid.sys. The "hid" rang a bell as being related to Human Interface Device, so it seemed like I migh...

So DDP|ST has been out of support for a bit and obviously hardware encryption has taken a bit of a knock lately, but some of you may be stuck with some Windows 7/OPAL setups for the time being so I'll write this up. The scenario was that DDP|ST was installed into an image - target machine was a Dell Latitude E7470 with a LiteON SED SSD. Everything was ticking along in the usual way until ready to hit "Encrypt" on the SED. On doing so... nothing happens. The Encrypt button is greyed but it is possible to back out of the section or close the UI entirely. I remembered overnight that I had seen this before - it required uninstalling and reinstalling the DDP|ST (including the usual PITA manual uninstall order, preserving Authentication data when asked, requiring reinstatement of the preboot text notices and removing undesired authentication methods). The log files for DDP|ST are in \ProgramData\dell\Dell Data Protection\ but as yet I haven't figured out a cause. Of cou...