Arqade is a question and answer site for passionate videogamers on all platforms. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

enter image description here

Why does Mumble require me to close Steam or Chrome on Setup?

What does it change within Steam that makes it necessary and why does it touch it at all?

share|improve this question
German is hard to understand >.< (at least for me =P) – Michel Jan 8 '13 at 11:40
Sorry, I didn't downvote you =X Also, the close vote, I believe, is because Mumble is not game related. It's more like a Mumble issue, not a game issue. so off-topic. But, as I'm not sure about it, I'm not voting (yet) to close your question. PS: The comment was a funny comment only =/ – Michel Jan 8 '13 at 11:44
I think it is very well on topic. Gaming related software is allowed, so this is related to gaming since mumble is used by many gamers. Also, it relates to Steam. So I can't see why it should be offtopic. – user28015 Jan 8 '13 at 12:14
Does it happen only when you install it, or does it continue when you try to use it. i.e. Can you USE Mumble the same time as Steam and Chrome? – Ilya Melamed Jan 8 '13 at 13:00
I'd bet it's either some system/common file or the app is just being overprotective and asking you to shut down most/all open applications. I know several people who use steam and mumble and don't have problems, so don't assume this means they interfere – Ben Brocka Jan 8 '13 at 13:59

If you have Mumbles overlay enabled and Mumble running, it will inject into any applications using Direct3D (DirectX). In this case, this seemingly happened to chrome.exe and steam.exe.

As the overlay DLL is updated the injected code should be invalidated/dropped, thus the installer lists these applications and informs that they should be closed.

As the overlays in-memory information structure may change between versions and as that information is shared system-wide (shared memory) using both “old” injected code as well as “new” injected code (previous vs. current Mumble overlay DLL version) is discouraged - and thus the applications should be closed.

In the current code-base of Mumble steam.exe as well as chrome is blacklisted (since 2012/2011). I would guess you still use a very outdated version of the default blacklist. In Mumbles settings you can use restore to default to set the new defaults as your current blacklist.

share|improve this answer

Try running the Mumble .msi install package as follows:

msiexec.exe /i mumble-1.2.4.msi /l* log.txt

Continue the installation until the dialog appears and look at the last couple of lines in log.txt. It should be pretty clear which file that is in use. My guess is msvcr100.dll.

share|improve this answer
There would be no technical reason for that. If properly programmed, a .dll can handle multiple clients that need it when running. IT is also not necessary to close other programs that use this file unless you want to replace it. And if a simple voice program wants to replace the C/C++ Runtime of my OS, then I would be really worried and assume malware. – Assylum Jan 3 '14 at 17:51
I doubt msvcr100.dll would be an issue. If it is listed where you described, I doubt this approach to finding the culprit is a good approach. – Kissaki Jan 3 '14 at 17:52
@Assylum Replacing a shared file is exactly what the installer wants to do according to OP. Inspecting the latest Mumble .msi reveals that its tables do indeed contain install references for msvcp100.dll and msvcr100.dll to SystemFolder (which, depending on your Windows and how you run the installer may or may not be shared between applications). In fact, these two files are the only files in the installer that seem to be marked for installation to a system folder. Historically it has been very common for applications to update common libraries system-wide. I wouldn't worry. – Zero3 Jan 6 '14 at 12:23
@Kissaki See my comment above. As these are the only two files to be installed to a system folder, it would make sense. Nevertheless, it was a guess, and I do believe finding the conflicting file using the command line arguments I provided is a good approach to finding the culprit. Why would it not be a good idea? – Zero3 Jan 6 '14 at 12:24

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.