question

Callum-3836 avatar image
0 Votes"
Callum-3836 asked PolkCarl-0048 commented

Post Server 2016 -> 2019 upgrade, dedup.sys BSOD

Similar issue reported here, was asked to open a new thread by @Docs-4663 .

I've recently performed an in-place upgrade from Server 2016 => 2019 (non-domain).

System had been configured with data deduplication (mostly VHDs for Hyper-V). Ever since the upgrade, attempting to access or reverse dedupe (start-dedupejob -type unoptimize) the system will crash with 0x07E dedup.sys

(0x0000007E (0xFFFFFFFFC0000094, 0xFFFFF80BE9E82F29, 0xFFFFA00F5D4BA3E8, 0xFFFFA00F5D4B9C30)))

Attempting to copy the data off the drive results in the same error. I have spun up a 2016 VM in an attempt to copy/reverse dedupe and it fails stating revision is unknown. Spun up a fresh 2019 to do the same and receive the same bugcheck as the upgraded system.

Logs have been shared here

Hindsight being 20/20 I should've checked these things before the upgrade but now I'm in this situation, any help is greatly appreciated.


windows-server-2019
· 2
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

I tried to reply on your ServerFault thread, but was told only answers ;) Anyways, I am/was in the same boat: Upgraded a Server 2016 w/ DeDupe enabled to 2019 over the weekend. Saturday night, when dedupe operations occur, it BSOD'd; was confused, but wrote it off. Happened again on Saturday, and then on Sunday. Dug into the dumps, and they look exactly like yours.

My solution was to build a Server 2016 with the May patch level, mount the impacted drive on it, and then copy as much as I could. Once I got to the files I couldn't grab, due to the version mismatch, I violently copied it over the network from the 'broken' 2019, just absorbing the BSODs (it BSOD'd like... 5 times, until I was able to get everything off). Then, re-mounted the 'new' drive, removed the 'old' deduped drive, and removed Deduplication completely; YOLO. Never doing that again.

I have no solution for you, but just wanted to let you know you for sure found a 'bug', and I'd try to open a case, if I were you.

1 Vote 1 ·

Thanks for letting me know!

I've ended up doing much of the same, mounting the VHDXs where I can and recover as much data as the system will let me. At least I'm using VMs to mount the drives so as not to impact anything else. Looks for sure like we're hitting some sort of bug though.

0 Votes 0 ·
DSPatrick avatar image
0 Votes"
DSPatrick answered PolkCarl-0048 commented

In-place upgrades are never recommended and can be problematic. I'd suggest standing up a new one from clean installation media, patch fully and migrate roles over to it. This will at least remove this from the equation.

--please don't forget to upvote and Accept as answer if the reply is helpful--



· 4
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Thanks for the response. I understand it's not the recommended course of action, it was mainly a lab environment.

I have tried to access the drive using a clean installation of both 2016 and 2019 with the dedupe role added, neither were able to access the data. 16 reports unknown revision whilst 19 BSOD's same as the upgraded server.

Hardware is not a factor, the clean machines were running through VMWare on a separate machine, the drive has been checked with no faults found. Issue appears to be with accessing the deduplicated data, mainly in VHDX files.

0 Votes 0 ·

Sounding like the data may have some sort of corruption. This one appears to be beyond the scope of forums support. You can start a case here with product support.
https://support.serviceshub.microsoft.com/supportforbusiness

--please don't forget to upvote and Accept as answer if the reply is helpful--






0 Votes 0 ·

I seemingly hit this recently as well.

I've run dedup since 2016 on my pet server, which is mostly used for Hyper-V hosting. It was upgraded to 2019 about a year ago and has worked without issue for the most part.

The VMs work fine, but I've just discovered that when one of my ISOs is read, it triggers a DEDUP.SYS bluescreen (I thought it was a VM guest DoS bug at first, but it's just a regular file read bug from the look of it.)

This is suboptimal and I'd argue there should be better failure modes than that for a problem with some aspect of the dedup process.

0 Votes 0 ·

Yet they are fully supported and documented by Microsoft. Yes Admin experience its not a good way to go.

0 Votes 0 ·
Docs-4663 avatar image
0 Votes"
Docs-4663 answered Docs-4663 edited

This is the link from the prior thread: https://docs.microsoft.com/en-us/answers/questions/424621/bsod-dedupsys-after-inplace-upgrade-server2016-201.html

If you clean install then there is no further troubleshooting unless there are new BSOD.

https://www.windowsservercatalog.com/
https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2016?filetype=ISO

If you want to check the current installation then you can run:
sfc /scannow
dism /online /cleanup-image /restorehealth


.
.
.
.
.

Please remember to vote and to mark the replies as answers if they help.

On the bottom of each post there is:

Propose as answer = answered the question

On the left side of each post: Vote = a helpful post
.
.
.
.
.

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.