When Windows media player (WMP) is open, any attempt to open it again simply reactivates the existing WMP window. WMP is running as a single instance. It uses a relatively well known methods for this, creating a named mutex on startup and seeing if it already exists (by calling GetLastError and comparing with ERROR_ALREADY_EXISTS). WMP uses a mutex called "Microsoft_WMP_70_CheckForOtherInstanceMutex" and this name seems to be consistent between WMP versions (at least starting from Windows XP).
Mark Russinovich showed this mutex in the latest addition of Windows Internals. Let’s run an instance of WMP and look at process explorer’s lower pane when configured to show handles:
The session prefix indicates this object was created in the logged in user’s session (session 1 in Vista and up).
We can manually close the handle using Process Explorer again. Just right click the handle and select “Close Handle”. After this – you can open another WMP – that new WMP will try to create that named mutex – and will succeed.
Closing a handle like this may be catastrophic – the process doesn’t know the handle was closed “behind its back”, so any use of this handle will fail. Even worse, a new handle in that process may be created pointing to another object altogether, without the process realizing it. In this particular case, it’s benign.
What if you wanted to automate this, so that you could open multiple instances of WMP and play several video/audio files at the same time? Or pause one, play another, etc.? I think this has its uses.
How would we go about doing it? How can we close the correct handle like Process Explorer does?
Maybe we can call OpenMutex with the above name and close the handle twice… this won’t work, as after the first CloseHandle, the handle becomes invalid and the next CloseHandle simply fails.
What we need is to get to the handle inside the WMP process and close it from there. Easier said than done…
There are basically two ways we can go:
1. Write a driver, that can access the EPROCESS kernel structure, find the handle table for that process, locate the handle and close it. Theoretically possible, but many issues involved: EPROCESS is undocumented, except through the kernel debugger – not much fun to work with; installing a driver required user consent if UAC is active – not so user friendly; driver by its own nature is much dangerous to use (blue screen possible), …
2. Inject code into the WMP process that will scan the handle table from user mode, locate the handle and close it. Sounds better, easier; just one caveat: no Windows API allows scanning handles and getting the name of the object their pointing at.
So, we’ll go with option 2. Injecting code into a process is fairly well documented, e.g. by calling CreateRemoteThread pointed at LoadLibrary (because kernel32 is loaded at the same virtual address in every process) where our DLL is loaded into the other process and does the deed in its DllMain. The complete details can be found in Jeffrey Richter’s book Windows Via C/C++ (5th edition), or look at the source code accompanying this post.
Getting our code to execute under a WMP process is possible. The only thing remaining is handle enumeration. Although there is no official Windows API to do this, there is a native API (inside ntdll.dll) called NtQueryObject. It’s partially documented in the Windows SDK and in the Windows Driver Kit (WDK) (under ZwQueryObject) – there is a lot of symmetry in the APIs from ntdll and the executive. This function allows getting information given a handle. So, we can scan the handles, starting from 4 (the first legal handle value) up to some limit and look for an object with the aforementioned name. When we find it – just CloseHandle it and we’re done.
Here’s the prototype for NtQueryObject that we need:
typedef enum _OBJECT_INFORMATION_CLASS {
ObjectBasicInformation, ObjectNameInformation, ObjectTypeInformation,
ObjectAllInformation, ObjectDataInformation
} OBJECT_INFORMATION_CLASS;
typedef struct _UNICODE_STRING {
SHORT Length;
SHORT MaxLength;
PWSTR String;
} UNICODE_STRING, *PUNICODE_STRING;
typedef struct _OBJECT_NAME_INFORMATION {
UNICODE_STRING Name;
WCHAR NameBuffer[1];
} OBJECT_NAME_INFORMATION, *POBJECT_NAME_INFORMATION;
extern "C" NTSYSAPI LONG NTAPI NtQueryObject(
__in_opt HANDLE Handle,
__in OBJECT_INFORMATION_CLASS ObjectInformationClass,
__out_bcount_opt(Length) PVOID ObjectInformation,
__in ULONG Length,
__out_opt PULONG ReturnLength
);
We need to use ObjectNameInformation (which is undocumented).
Here’s the way we can find the correct handle and close it:
OBJECT_NAME_INFORMATION* ninfo = (OBJECT_NAME_INFORMATION*)::malloc(1024);
// run through all handles until we find it
for(int h = 4; h <= 0x120; h += 4) {
LONG status = NtQueryObject((HANDLE)h,
ObjectNameInformation, ninfo, 900, NULL);
if(status == 0) {
PWSTR name = ::wcsrchr(ninfo->NameBuffer, L'\\');
if(name != NULL && ::lstrcmpW(name + 1, mutexName) == 0) {
// found it!
::CloseHandle((HANDLE)h);
break;
}
}
}
::free(ninfo);
mutexName is the name we’re after.
Attached is the source code and the executable. The DLL is stored as a resource in the EXE, and extracted at runtime to a temp folder. This trick makes it easy to distribute – only one file is required.
Enjoy Media Player multi instancing!