Tuesday, February 05, 2008

Issues Installing Patchset 10.2.0.3.0 on Windows XP

When attempting to install the Patchset 10.2.0.3.0 upgrade OUI complainted about a msvcr71.dll file in use. All Oracle services were shutdown, as directed by the Installation Guide. So this file shouldn't be in use by any Oracle executable. So where the culprit is? I found it by means of the Process Explorer, this is an utility that can be downloaded from the microsoft site, by navigating through the url: http://www.sysinternals.com/, the Microsoft Technet site can be reache, a couple of clicks and you're done, you can download it. A useful tool is the ListDLL too.

I found a svchost.exe process grabbing the msvcr71.dll file, I just killed it and the Installation process just went on to the end. I should point out that killing an OS process is a very serious matter, don't kill it unless you are absolutely sure what you are killing. DLL's shouldn't be locked by third party processes, so Oracle can just smoothly perform the upgrade. By means of the graphical tool previously mentioned I managed to know which process was locking the DLL.

Side Note, msvcr71.dll: is a module containing standard C library functions such asprintf, memcpy, and cos. It is a part of the Microsoft C RuntimeLibrary.

10 comments:

Nicolas Gasparotto said...

I never notice such issue on 10g. That remind me old age (not too old) with the 9.2.0.5 patchset.
A workaround was to rename the ORACLE_HOME directory, reboot the server, rename back the ORACLE_HOME, and restart the installation.

By the way, nice to see you are blogging now.
For your comfort, you could activate the word verification.

Hector R. Madrid said...

OK, thanks for your feedback. The last time I faced a similar issue was when I performed an upgrade when applying the 9.2.0.7.0 and 9.2.0.8.0 patchset on windows platforms. It was a repeatable issue when IIS was active.

Doug said...

I noticed many svchost processes running... Killing one, killed the computer. I guess another work around (for the Oracle 10.2.0.4 patch) would be to just select "Ignore" and not replace msvcr71.dll. I wonder why Oracle does not follow the practice of replacing files-in-use on the next reboot? As an aside, this Oracle patch is ridiculously complex and time-consuming... It is pages full of warnings, advisories, things to check and do. What happened to the concept of just dbl-clicking on Setup and let Setup do all the work. Oracle is simply pushing work to their customers...

Hector R. Madrid said...

Doug, killing an svchost process is a serious matter. I suggested using a microsoft tool to find out which one was the actual process that has to be killed. If killing other process, unexpected results will be obtained.

Doug said...

Thanks Hector for reminding me that you used a sysinternals utility to determine the exact svchost which was causing a lockup on msvcr71. I have used process monitor before but didn't think to use it here... Guess I was determined to play fast-and-loose with this development box.

Hector R. Madrid said...

Doug, I do thank you for your feedback. I should have emphasized about how to deal with svchosts, so I added more notes in my posting. As Nicolas has stated, he has never faced such an issue on 10g, and that is the way this should be, but in my particular scenario I found out that IIS was active, so several DLL's were locked. I figure out, but not still confirmed, this had to do with PATH environment issues.

Unknown said...

Just stop the below windows service :
Shutdown the Distributed Transaction Coordinator through the Computer Management Services Control.

or.
You may want to refer to below Metalink Document

Note.418479.1 - Files in Use errors, when running Opatch to apply patches on Windows:

Luis Ernesto.

ynar said...

I believe it is a path issue as well. There are several places where this dll can be found in windows. When the oracle PATH entry is near the front, other applications pick up oracle's dll instead of their own copy. You can see which services use it by using the sysinternal's procexp.exe and running "tasklist /svc" on the command line. I found that changing the path allowed me to continue with the installation since there were a dozen services which had placed a claim on poor oracle's msvcr71.dll.

Unknown said...

Hi All !
This occurred in 10.2.0.4 too ! And the solution of using ProcessExplorer to find out what process are using msvcr71.dll is great !!
Thanks a lot !

Paul said...

I ran into same lock on msvcr71.dll (twice) on Windows Server 2008 (SP2) with no IIS ... fortunately I was using virtuals and was able to revert to a pre-oracle state and before applying 10.2.0.4 upgrade from 0.3; I just moved the oracle path variable to end of the path variable string and the upgrade went smooth. Very helpful! Thanks!!