tags:

views:

187

answers:

2

How to determine whether a particular process is a WPF application running or not?

In Snoop, the author uses this code below to check this condition ~

foreach (ProcessModule module in process.Modules)
{
     if (module.ModuleName.Contains("PresentationFramework.dll") ||
        module.ModuleName.Contains("PresentationFramework.ni.dll"))
    {
       isValid = true;
        break;
     }
}
+1  A: 

I just tested this on 64-bit Vista, and it works well. The WPF process contains PresentationFramework.ni.dll from the native images folder (where assemblies go when they have been ngen'd).

Can you elaborate on why you think this does not work?

Jerry Bullard
Let me tell you about my envoirnment first. Env:Main OS : Windows 2008 R2 64 bitsHyper-V OS : Vista 64 bits Business Edition.Visual Studio 2008I created WPF applicaiton (called WpfApplication1) in VS 2008 and run it by double-clicking the exe. Then, I run Snoop to detect my WpfApplication1 but it doens't show in combobox.
Thanks. It's working fine when I re-compile both Snooop SourceCode and WpfApplication1 with x64 setting.
+3  A: 

Apparently a 32-bit process cannot enumerate the modules of a 64-bit process. It raises the following Win32Exception :

Only part of a ReadProcessMemory or WriteProcessMemory request was completed

That's probably a limitation of the Process class, there must be a way around it using API methods...

The same thing works fine if the process is also 64-bit...

Regarding Snoop, there isn't a 64-bit version available for download, but since the source is also available, you could compile it to x64

EDIT: if your process is 64-bit and the running WPF app is 32-bit, Process.Modules doesn't seem to contain PresentationFramework either...

System.Diagnostics.ProcessModule (TheWPFApp.exe)
System.Diagnostics.ProcessModule (ntdll.dll)
System.Diagnostics.ProcessModule (wow64.dll)
System.Diagnostics.ProcessModule (wow64win.dll)
System.Diagnostics.ProcessModule (wow64cpu.dll)
Thomas Levesque
OK, +1 for the great catch.The problem is the way Windows loads 32-bit apps on a 64-bit O/S under the Windows on Windows (WOW) umbrella. When inspecting the 32-bit process from the outside, only the 64-bit wrapper around the actual 32-bit process is visible using this technique.I found in my test app that I could repro this by changing the "Platform target" on the Build tab from "Any CPU" to x86. I'm not clear why the installer for Snoop has been set to x86 because the downloaded source for the installer is set to "Any CPU".
Jerry Bullard
Probably because the author's OS is 32-bit...
Thomas Levesque
It should be independent of the author's O/S if AnyCPU is selected, but the following links could shed some light on the problem:http://social.msdn.microsoft.com/Forums/en-US/netfx64bit/thread/d207eb14-c06b-41de-b553-4a3ab3d53b30http://www.hanselman.com/blog/BackToBasics32bitAnd64bitConfusionAroundX86AndX64AndTheNETFrameworkAndCLR.aspx
Jerry Bullard
Well, I have Win7 64-bit, and when I target "AnyCPU" platform, VS2008 prevents edit-and-continue in debug and gives the following message : "Changes to 64-bit applications are not allowed". Apparently this is the normal behavior that AnyCPU assemblies run with the bitness of the OS
Thomas Levesque
Thanks. I think both Snoop Source Code and my WPF sample applicaiton need to be recomplied with x64. If one of them is Any CPU or x84 then it doens't work.