Personally, I divide the storage space of my hard disks up in partitions. In my anecdotal experience, Windows doesn't do much adjusting of file/folder rights (also known as ACL) on partitions that are not the C:\ partition. I always yank user related data from the partition where Windows is installed and put those on a different partition. I also make partitions for generic data storage and even one dedicated to Temp/TMP files.
Never have I experienced ACL changes in these partitions after updates. Honesty demands that I never looked for such changes, but if everything remains working like it is configured, there has not been a real reason to do such research. Resetting my default software for specific file extensions, that does happen and is really not appreciated.
From your description I gather that things go bad after explorer.exe tries to access functionality encapsulated in file: ntdll.dll. Perhaps it might be a good idea to make a hash from a known good copy of the exact same version of that specific file and compare that hash with the hash from that file on the computer where you encounter this error.
If those do not match, that file has been compromised. Can be damage, can be that explorer.exe runs out of allotted waiting time for that specific functionality it needs from ntdll.dll, it can be lots of things. Even if they match, that file can be compromised by a bad/(too slow) block on the hard disk itself.
For that last scenario I even have an example of what happened to me not one week ago. While making backups from an Oracle database server (on Windows), I suddenly get a BSOD. After that, the database wouldn't start at all anymore. Reading out S.M.A.R.T. data from the hard disk causing the problem, no problem whatsoever. Looking at the Oracle logs, I see ORA-03113 errors appear (related to file I/O errors). Doing a complete CHKDSK (command-line version) on the offending hard disk, again no problem detected. Still, Oracle keeps complaining. It wouldn't even allow me to purge content from certain files, which is the common resolution for this problem.
In the end I cloned the hard disk bit for bit onto a brand new hard disk, then Oracle did allow me to purge these files and the database runs fine again. Further investigation on the offending hard disk (which was deemed in excellent health by S.M.A.R.T. and Windows itself) revealed that the blocks where these files actually reside on the hard disk had an access time greater than 500 milliseconds. While in essence nothing was wrong according to Windows and S.M.A.R.T., I still ended up with an useless database (located on a 3 year old hard disk).
Something similar might be happening on your system too. If your Windows installation even allows it, you could try to make a copy of the ntdll.dll file in the same folder where you find it. You might be able to rename the original 'ntdll.dll' to 'ntdll.org.dll' and rename the copied file back to 'ntdll.dll'. That way the file has relocated to a different and hopefully good functioning part of your hard disk. If you can now go through your reproduction steps without a problem, you have (temporarily) fixed your problem. I still would consider buying a new hard disk ASAP, clone your old disk onto the new disk and re-purpose the old disk for keeping non-essential data.
