August 9, 20206 yr 1 minute ago, daniel_k said: @Dave-H and @Dylan Cruz I've fixed it! Found an easy way to fix Office 2010 and not break TLS updates. Get KB3081320 from WU Catalog, extract it and copy dssenh.dll to C:\Program Files\Microsoft Office\Office14. That's it. Hey, that's awesome! Seems like I already downloaded that, let me see if I have that. So installing the update isn't enough, a manual DLL override is required?
August 9, 20206 yr Author Wow, great news! My version of dssenh.dll in \system32 is 5.1.2600.7345. The version in KB3081320 is 5.1.2600.6924. I guess a subsequent update changed the system version, probably causing the Office encryption problem, but if the older version of the file is in the Office program folder it still uses that. Great result! Edited August 9, 20206 yr by Dave-H Addition
August 9, 20206 yr 4 minutes ago, Dylan Cruz said: So installing the update isn't enough, a manual DLL override is required? Actually, it shouldn't be installed. You are just "providing" an older and working copy of the DLL for Office to work with.
August 9, 20206 yr 4 minutes ago, daniel_k said: Actually, it shouldn't be installed. You are just "providing" an older and working copy of the DLL for Office to work with. Were you able to do an online, live replace? Seems Replacer might be required here...
August 9, 20206 yr 1 minute ago, Dylan Cruz said: Were you able to do an online, live replace? Seems Replacer might be required here... Used Replacer, it works! Thanks @daniel_k - this is great!
August 9, 20206 yr Author That file doesn't exist by default in the Office program folder, only in \system 32. Putting any version in there should not be a problem.
August 9, 20206 yr 2 minutes ago, Dave-H said: That file doesn't exist by default in the Office program folder, only in \system 32. Putting any version in there should not be a problem. Whoops, I replaced the system32 one Let me change it back! Office worked with that, but who knows what else that could've broken... better to do it that way!
August 9, 20206 yr Author Yes, works fine with the older file just in the Office program folder, no need to change the system file!
August 9, 20206 yr 6 minutes ago, Dave-H said: Yes, works fine with the older file just in the Office program folder, no need to change the system file! Did you have to reboot? it didn't work after I copied it in there once the system file was back EDIT: I rebooted and it's still broken... ? Edited August 9, 20206 yr by Dylan Cruz
August 9, 20206 yr 23 minutes ago, Dylan Cruz said: Did you have to reboot? it didn't work after I copied it in there once the system file was back EDIT: I rebooted and it's still broken... ? @daniel_k @Dave-H Do I need to enable DLL redirection or something, so it uses the DLL in Office14, not system32? It's still broken for me unless I replace the system32 copy
August 9, 20206 yr Author I'm only working from my very faulty memory here, but is that dll listed in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs? IIRC, if it is there programs will always use the version in system32. If it's there, remove it and try again.
August 9, 20206 yr 2 minutes ago, Dave-H said: I'm only working from my very faulty memory here, but is that dll listed in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs? IIRC, if it is there programs will always use the version in system32. If it's there, remove it and try again. Unfortunately, I don't see it there
August 9, 20206 yr 5 minutes ago, Dylan Cruz said: Unfortunately, I don't see it there What happens if you run Dependency Walker on winword.exe? @Dave-H I don't see it loading dssenh.dll at all for me there, do you? Edited August 9, 20206 yr by Dylan Cruz
August 9, 20206 yr @Dylan Cruz I have no idea what is going wrong on your system. I've just copied dssenh.dll to the Office folder. That's all.
August 9, 20206 yr Author 13 minutes ago, Dylan Cruz said: What happens if you run Dependency Walker on winword.exe? @Dave-H I don't see it loading dssenh.dll at all for me there, do you? No, me neither. Some background on DLL loading priorities here. Doesn't seem to solve the problem though! Edited August 9, 20206 yr by Dave-H Quote added
Create an account or sign in to comment