The problem of oracle dll files being still active (and locked against modification) inspite of a clear shutdown of all oracle services on windows has been around for lightyears it seems.
What changes, though, is the net of dependencies that has to be checked prior to an upgrade or patch execution to find the processes that actually keep hooking up the dll’s in question. I was hit again lately, when trying to apply the server 188.8.131.52 Patch 18 (the APR2013 bundle patch) on win x64. The infamous error message on executing
opatch apply read:
e:\_downloads\p16345834_112030_MSWIN-x86-64\16345834>opatch apply Oracle Interim Patch-Installationsprogramm Version 184.108.40.206.3 Oracle Home : e:\oracle\product\11.2.0\dbhome_2 Central Inventory : C:\Program Files\Oracle\Inventory ... Verifying environment and performing prerequisite checks... ... Prerequisite check "CheckActiveFilesAndExecutables" failed. The details are: Following files are active : e:\oracle\product\11.2.0\dbhome_2\bin\oci.dll ... Recommended actions: OPatch needs to modify files which are being used by some processes. OPatch failed with error code = 41
I’m not going to keep quite about the fact that the good old approach of just renaming the affected dll files will still work to circumvent this bothersome issue.
However, remembering the newer (at least to me)
tasklist shell program, i was curious to find out about the processes that still hold on to in fact
tasklist with the
/m option in fact devivered the expected results, showing
vmtoolsd.exe as the culprits.
Abbildname PID Module ========================= ======== ============================================ ... vmtoolsd.exe 1920 ... oci.dll ... dllhost.exe 384 ... oci.dll ...
vmtoolsd.exe was easily identfied to be a child of the VMware Tools Service. A
net stop "VMTools" cleared the scene (this will not actually also stop
vmtoolsd.exe, but it worked, so I don’t care) as another dedicated, that is, filtered execution of
tasklist /m /fi "imagename eq vmtoolsd.exe" revealed.
dllhost.exe I needed to take a couple of searches around the net to safely relate the process to the COM+-Systemanwendung (system application) Service.
net stop "COMSysApp" did the trick on that side, again double checked with
That’s it. No more complains from
ps. Do not forget to also do that
net stop/start "MSDTC" for the Distributed Transaction Coordinator but this is even in the oracle docs already, which you will alway read, I suppose.
Have fun, P