Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

FilesInUse detection problem

21 views
Skip to first unread message

Simon Scott

unread,
Apr 16, 2008, 12:53:02 PM4/16/08
to
Hi,
I am encountering Info 1603: when I don't expect it. Situation is this.

My installation is redistributing the VC++ 7.1 runtime DLLs to my
application folder (as per documented recommendations). On uninstall, I'm
getting the FilesInUse dialog asking me to shut down unrelated applications
(often including IEXPLORE.exe).
When I look in the install log, I see
Info 1603.The file C:\Program Files\Trillium
Software\MBSW\11.5\bin\msvcr71.dll is being held in use by the following
process: Name: IEXPLORE, ID: 4476, Window Title: (not determined yet). Close
that application and retry.

However, using LISTDLLS against that process I get this:

0x7c360000 0x56000 7.10.6030.0000 C:\WINDOWS\system32\MSVCR71.dll

So it looks to me as though MSI is matching the base name of the dll , and
not considering the whole path.

Is this a known issue? My version of msi is Windows ® Installer. V
3.01.4000.1823

--
Regards
Simon

Linda Liu[MSFT]

unread,
Apr 17, 2008, 5:35:04 AM4/17/08
to
Hi Simon,

I performed tests based on your description on both Windows XP and Vista,
but didn't reproduce the problem on my side.

I create a Setup project with VS2005. Add a .txt file and the MSVCR71.dll
file in the 'Application Folder' of the Setup project. Then build the
project.

After I install the resulting MSI package on my test machine, both the .txt
file and the MSVCR71.dll are installed in the specified application folder.
I launched IE. Then I uninstall the MSI package and both the .txt file and
the MSVCR71.dll file are removed from the test machine successfully.

I get the same result on Windows XP and Vista. The version of Windows
Installer on Windows XP is 3.1.4000.4039 and that on Window Vista is
4.0.6000.16386.

What's the OS version on which you install your MSI package?

You may have a try installing your MSI package on other machines with
higher version of Windows Installer to see if the problem still exists.

Sincerely,
Linda Liu
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.


Simon Scott

unread,
Apr 17, 2008, 10:04:00 AM4/17/08
to
Hi Linda,
Thanks for your help. I am running my tests on Windows XP, the version of
msi.dll is 3.1.4000.4039.

There is one more thing I should have mentioned. To reproduce the problem
you need to have one program running that is really using the msvcr71.dll
that is about to be uninstalled.
In my application I have a service which is running when I uninstall. The
uninstall stops and uninstalls the service program. The service is using the
msvcr71.dll. But if I stop the service before attempting the uninstall I
don't get the FilesInUse message.

--
Regards
Simon

Linda Liu[MSFT]

unread,
Apr 21, 2008, 10:19:21 PM4/21/08
to
Hi Simon,

Thank you for your reply!

> In my application I have a service which is running when I uninstall.

Is the service you mentioned installed by the same MSI package that
installs your application or a separate MSI package?

I suggest that you uninstall the MSI package and run the service and use
"Process Explorer" to see which MSVCR71.dll is loaded by the service.

Then stop the service and install the MSI package and run the sevice again.
Use "Procress Explorer" to see which MSVCR71.dl is loaded by the service
now.

FYI, you can get "Process Explorer" from the following link:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Please try the above steps and let me know the results.

Sincerely,
Linda Liu
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.

This posting is provided "AS IS" with no warranties, and confers no rights.

Simon Scott

unread,
Apr 22, 2008, 6:27:01 AM4/22/08
to
Hi Linda,

The service is un/installed by the same MSI package. So it is a little
difficult to follow exactly the path you suggest. What I have done is this -
I have used the LISTDLLS program (from the same sysinternals site as
procexp), to list the dlls loaded by the service and an instance of
iexplore.exe before I uninstall. Then I have the log of the uninstall that
shows the 1603 messages. Excerpts from these files are listed below, if you
like I can zip and send the entire files.

This is from the service program ("scheduler.exe") that is uninstalled by my
package:

ListDLLs v2.25 - DLL lister for Win9x/NT
Copyright (C) 1997-2004 Mark Russinovich
Sysinternals - www.sysinternals.com

------------------------------------------------------------------------------
scheduler.exe pid: 4456
Command line: "C:\Program Files\Trillium
Software\MBSW\11.5\bin\scheduler.exe" "--name:TSS 11.5 - Scheduler"

Base Size Version Path
0x00400000 0xac000 2.00.0000.8109 C:\Program Files\Trillium
Software\MBSW\11.5\bin\scheduler.exe
0x7c900000 0xb0000 5.01.2600.2180 C:\WINDOWS\system32\ntdll.dll
0x7c800000 0xf5000 5.01.2600.3119 C:\WINDOWS\system32\kernel32.dll
0x7e410000 0x91000 5.01.2600.3099 C:\WINDOWS\system32\USER32.dll
0x77f10000 0x47000 5.01.2600.3316 C:\WINDOWS\system32\GDI32.dll
0x77dd0000 0x9b000 5.01.2600.2180 C:\WINDOWS\system32\ADVAPI32.dll
0x77e70000 0x92000 5.01.2600.3173 C:\WINDOWS\system32\RPCRT4.dll
0x77fe0000 0x11000 5.01.2600.2180 C:\WINDOWS\system32\Secur32.dll
0x7c3c0000 0x7c000 7.10.6030.0000 C:\Program Files\Trillium
Software\MBSW\11.5\bin\MSVCP71.dll
0x7c360000 0x56000 7.10.6030.0000 C:\Program Files\Trillium
Software\MBSW\11.5\bin\MSVCR71.dll

Here is the output from the iexplore.exe:

ListDLLs v2.25 - DLL lister for Win9x/NT
Copyright (C) 1997-2004 Mark Russinovich
Sysinternals - www.sysinternals.com

------------------------------------------------------------------------------
IEXPLORE.EXE pid: 4476
Command line: "C:\Program Files\Internet Explorer\IEXPLORE.EXE"

Base Size Version Path
0x00400000 0x19000 6.00.2900.2180 C:\Program Files\Internet
Explorer\IEXPLORE.EXE
0x7c900000 0xb0000 5.01.2600.2180 C:\WINDOWS\system32\ntdll.dll
0x7c800000 0xf5000 5.01.2600.3119 C:\WINDOWS\system32\kernel32.dll
0x77c10000 0x58000 7.00.2600.2180 C:\WINDOWS\system32\msvcrt.dll
0x7e410000 0x91000 5.01.2600.3099 C:\WINDOWS\system32\USER32.dll
0x77f10000 0x47000 5.01.2600.3316 C:\WINDOWS\system32\GDI32.dll
0x77f60000 0x76000 6.00.2900.3314 C:\WINDOWS\system32\SHLWAPI.dll
0x77dd0000 0x9b000 5.01.2600.2180 C:\WINDOWS\system32\ADVAPI32.dll
0x77e70000 0x92000 5.01.2600.3173 C:\WINDOWS\system32\RPCRT4.dll
0x77fe0000 0x11000 5.01.2600.2180 C:\WINDOWS\system32\Secur32.dll
0x7e290000 0x171000 6.00.2900.3314 C:\WINDOWS\system32\SHDOCVW.dll
0x77a80000 0x94000 5.131.2600.2180 C:\WINDOWS\system32\CRYPT32.dll
0x77b20000 0x12000 5.01.2600.2180 C:\WINDOWS\system32\MSASN1.dll
0x754d0000 0x80000 5.131.2600.2180 C:\WINDOWS\system32\CRYPTUI.dll
0x76c30000 0x2e000 5.131.2600.2180 C:\WINDOWS\system32\WINTRUST.dll
0x76c90000 0x28000 5.01.2600.2180 C:\WINDOWS\system32\IMAGEHLP.dll
0x77120000 0x8b000 5.01.2600.3266 C:\WINDOWS\system32\OLEAUT32.dll
0x774e0000 0x13d000 5.01.2600.2726 C:\WINDOWS\system32\ole32.dll
0x5b860000 0x54000 5.01.2600.2976 C:\WINDOWS\system32\NETAPI32.dll
0x771b0000 0xaa000 6.00.2900.3314 C:\WINDOWS\system32\WININET.dll
0x76f60000 0x2c000 5.01.2600.2180 C:\WINDOWS\system32\WLDAP32.dll
0x77c00000 0x8000 5.01.2600.2180 C:\WINDOWS\system32\VERSION.dll
0x76390000 0x1d000 5.01.2600.2180 C:\WINDOWS\system32\IMM32.DLL
0x629c0000 0x9000 5.01.2600.2180 C:\WINDOWS\system32\LPK.DLL
0x74d90000 0x6b000 1.420.2600.2180 C:\WINDOWS\system32\USP10.dll
0x773d0000 0x103000 6.00.2900.2982
C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03\comctl32.dll
0x7c9c0000 0x817000 6.00.2900.3241 C:\WINDOWS\system32\SHELL32.dll
0x5d090000 0x9a000 5.82.2900.2982 C:\WINDOWS\system32\comctl32.dll
0x5ad70000 0x38000 6.00.2900.2180 C:\WINDOWS\system32\uxtheme.dll
0x74720000 0x4b000 5.01.2600.2180 C:\WINDOWS\system32\MSCTF.dll
0x63000000 0x14000 7.05.0017.0013 C:\WINDOWS\system32\SynTPFcs.dll
0x75f80000 0xfd000 6.00.2900.3314 C:\WINDOWS\system32\BROWSEUI.dll
0x20000000 0x12000 6.00.2900.2180 C:\WINDOWS\system32\browselc.dll
0x77b40000 0x22000 5.01.2600.2180 C:\WINDOWS\system32\appHelp.dll
0x76fd0000 0x7f000 2001.12.4414.0308 C:\WINDOWS\system32\CLBCATQ.DLL
0x77050000 0xc5000 2001.12.4414.0258 C:\WINDOWS\system32\COMRes.dll
0x755c0000 0x2e000 5.01.2600.2180 C:\WINDOWS\system32\msctfime.ime
0x77a20000 0x54000 5.01.2600.2180 C:\WINDOWS\System32\cscui.dll
0x76600000 0x1d000 5.01.2600.2180 C:\WINDOWS\System32\CSCDLL.dll
0x77920000 0xf3000 5.01.2600.2180 C:\WINDOWS\system32\SETUPAPI.dll
0x7e1e0000 0xa2000 6.00.2900.3314 C:\WINDOWS\system32\urlmon.dll
0x10000000 0xd000 7.00.0009.0050 C:\Program Files\Adobe\Acrobat
7.0\ActiveX\AcroIEHelper.dll


0x7c360000 0x56000 7.10.6030.0000 C:\WINDOWS\system32\MSVCR71.dll

0x75e90000 0xb0000 5.01.2600.3019 C:\WINDOWS\system32\SXS.DLL


and here are the 1603 messages from the log:

Info 1603.The file C:\Program Files\Trillium
Software\MBSW\11.5\bin\msvcr71.dll is being held in use by the following
process: Name: IEXPLORE, ID: 4476, Window Title: (not determined yet). Close
that application and retry.
Info 1603.The file C:\Program Files\Trillium
Software\MBSW\11.5\bin\msvcr71.dll is being held in use by the following

process: Name: scheduler, ID: 4456, Window Title: (not determined yet).

Close that application and retry.

This seems to me to be a pretty clear demonstration of the problem. You can
see that listdlls for pid 4476 (iexplore) is reporting
C:\Windows\system32\msvcr71.dll as loaded, whereas msiexec is reporting that
the same process as C:\Program Files\Trillium......\bin\msvcr71.dll loaded.

Thanks for your help
--
Regards
Simon

Stephen Connolly

unread,
Apr 22, 2008, 3:34:19 PM4/22/08
to
I've seen this before, with MSI warning about potentially-locking
applications that in fact aren't in the frame. It would be interesting
to know whether if you proceed that the file can successfully be
replaced without shutting down IE (I suspect this will be the case.)
It looks like Windows Installer's using a heuristic method for
efficiency rather than drilling down through the list of loaded DLLs
for every process and being exact. I really don't like the out of the
box behavior for the filesInUse dialog anyway - for server side
installations we have to give users the best opportunity to shut down
locking processes, including those with no visible window, in order to
minimise the likelihood of a reboot - my team get bugs raised against
them whenever the installer prompts for a reboot!. The current
behavior means you have to do a lot of work to keep reboots to a
minimum.

One thing I would question, though, is why you are installing those
runtimes app local. Windows update will not know about them so you run
the risk of exposing your users to security or other vulnerabilities.

I'm also puzzled as to why that file is even being used at all, as the
default load order on newer OSs is to load from system32 in preference
to the files in the application folder, unless the application is
overriding this behaviour.

Simon Scott

unread,
Apr 23, 2008, 4:57:00 AM4/23/08
to
Hi thanks for your interest.
I have found that it is safe to "Ignore" the files in use dialog. After all,
the dlls aren't really being used by the processes anyway!

My installation used to install the runtimes to the system directory. Then I
found it wouldn't install on Vista, and when I checked the docs
(http://msdn2.microsoft.com/en-us/library/aa984684(VS.71).aspx) they say
clearly to install to the application's local folder. That fixed the Vista
problem but now I have this "FilesInUse that aren't" issue.

The description of the DLL search order here
http://msdn2.microsoft.com/en-us/library/ms682586(VS.85).aspx seems fairly
explicit that the application's local folder is always searched first?

Again, thanks for your interest

--
Regards
Simon

Linda Liu[MSFT]

unread,
Apr 27, 2008, 10:23:33 PM4/27/08
to
Hi Simon,

Sorry for my delayed reply!

I performed another test on this issue but still couldn't reproduce the
problem on my side.

I create a Setup project using VS2005 that installs an application as well
as MSVCR71.dll in the Program Files folder. After I install the resulting
MSI package, I copy the application from the Program Files folder to
another folder and run the application. Using Process Explorer, I can see
that this application loads the C:\Windows\System32\MSVCR71.dll.

Then I uninstall the MSI package. The application and MSVCR71.dll are
removed from the Program Files folder successfully without any problem.

The client machine I install the MSI package is Windows XP Professional SP2.

If possible, could you please send me an MSI package that could reproduce
the problem? To get my actual email address, remove 'online' from my
displayed email address.

0 new messages