I have had a further update from Microsoft support that they have acknowledged the issue and the development team is looking at it but “it may take a long time to get a released fix”.
I would say that this will go in the large basket of bugs that never get fixed so the best way to deal with it if at all possible would be to re-attach the volume to a Server 2016 machine, disable dedup and unoptimise the volume then re-attach the volume to Server 2019 enable dedup and optimise the volume.
Obviously that’s not going to be possible if you have a large amount of data and/or it is a physical server, but I really don’t see Microsoft fixing this given that it is still not even a documented acknowledged issue.
When I did testing on the fresh VM as described in my post, I created a new VM and installed Windows Server 2019. Then I attached a VHDX containing only data (not a system drive) which had already been deduped on a Windows Server 2016 system. When 2021-06 CU was installed on the Windows Server 2019 VM (which contains an updated dedup.sys file) it would BSOD when accessing data on that deduped volume.
It is worth noting too, on this test VM, if I replace the newer dedup.sys with the prior version then accessing the data on that deduped volume does not BSOD.
The steps to replace the driver were: (again this is a test VM only, not production)
Ok, I understand, your test doesn’t involve upgrade, only previous VHD attached, and when you change the newer version of dedup.sys(comes from KB5003646) with the older version from Windows Server 2019 with CU 2021-05, BSOD doesn’t appear. That’s enough, it can prove your idea.
I have submitted this case via our channel, let’s wait for update.
If you need further assistance such as remote session or deep research, you could open a request ticket with Microsoft support.