Unlocking oci.dll and friends when upgrading or patching oracle

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 11.2.0.3 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 11.2.0.3.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 oci.dll. Running tasklist with the /m option in fact devivered the expected results, showing dllhost.exe and vmtoolsd.exe as the culprits.

Abbildname                     PID Module                                      
========================= ======== ============================================
...
vmtoolsd.exe                  1920 ... oci.dll ...
dllhost.exe                    384 ... oci.dll ...

The latter 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.

Concerning 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 tasklist.

That’s it. No more complains from opatch.

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