I'm trying to use VDMEnumProcessWOW to find all 16 bit host processes on Vista. I call it, and it appears to not find any results even though I do have a 16 bit app running.
I've also tried calling VDMEnumTaskWOWEx with the process id I got for ntvdm.exe from Windows Task Manager, and that also returns no results.
ntvdm.exe has user name joeBlogs, and the application I've written to call VDMEnumProcessWOW is running as a service under the SYSTEM account. Is the problem that I need to have them running in the same session?
EnumProcesses works ok across sessions, but is VDMEnumProcessWOW different, or is there something else I'm missing? The documentation I've seen on this so far is a little sparse.
The VDM does contain the WowExec.exe task that the function's documentation says is required.
Thanks.
You can request the hotfix through this link.
Yes, a colleague just answered this. He ran into this problem before. It appears that VDMEnumProcessWOW does not work across sessions.
Also, Vista has some other problem enumerating 16 bit processes (I'm not exactly sure what they symptom is). There's a Microsoft supplied HotFix that is required to make this work.
Related
So I have spent that past week and a half working on code to simply setup the hook procedure for wh_shell for a program that will replace explorer.exe in the registry and will run as the main desktop program. There seems to be very little information and sources for using this outside of just the windows API which is a bit undescriptive and doesn't explain everything to a great detail. For some reason I just cant get it to work, no matter if I run it inside of explorer.exe, or if I replace the register and make it the default shell. I'm going to ask a couple of things in this post because I think that if you can answer one of these questions you likely have the answer to more.
So first I just have a question about hooks in general: When I run the SetWindowsHookEx(...) function -resource below- it says for var lpfn that a dll is not necessary if the hook is only used to monitor the current process. Now obviously when monitoring events such as window_created, those are events within a different processes which makes me think that the hookproc has to be within a DLL(which is how ive programmed so far). But this is questionable to me because when u are running SetWindowsHookEx(...) the process I wish to monitor do not yet exist until the user decides to start them. Do these processes notify the system when wh_shell events are being done so that I my hook doesnt need to get placed into every process upon creation, or is it more like when I run SetWindowsHookEx(...) with wh_shell that it will place a hook in all processes when the are created. The second resource states that the system just calls the hookproc when these things happen, so then do I even need a DLL, or what process does it need to be hooked to because I dont think it needs to be hooked into everything.
So second I have a question regarding setting my process as default shell - see resources - the resource states any process that registers itself as the default shell(which I assume is just modifying the registry to my process, if not and there is more please let me know) needs to call the SystemsParameterInfo(...) function. So first, does this func need to be called before running SetWindowsHookEx(...) or is there some expected spot it should be elsewhere in my code? Then in regards to the other variables it doesnt specify for, just curious what the recommended would be to set them as, like what are they set as for explorer.exe, and maybe a few other examples(including things NOT to do).
Finally for the sake of testing, using the console will be the most helpful to me here. The console will be used for input to run functions and commands for now(like open the register and swap back the shell to explorer.exe). If my hookproc is within a DLL, I need it to output some messages, I dont want to muddle the same console and I also dont even know if it will output to the same console, so what might be a recommended or potential solution for outputs(again this is temporary and for testing so it doesnt have to be perfect or even great)?
Also I would think windows 11 shouldn't be an issue, but I havent tested on windows 10 system...
I havent included any code as Im pretty sure most of this stuff can be answered without it and that its so few lines of code that its not like typical questions where its like examine my code and help me, maybe some example code you can show me would be really helpful.
Thankyou!
SetWindowsHookEx(...)
https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexa
defaultShell
https://learn.microsoft.com/en-us/windows/win32/winmsg/about-hooks#wh_shell
regards to WH_SHELL section
Testing Environment:
Windows 11 vm running in Hyper-V Manager
You haven't mentioned an important parameter in your description and that is the last argument of SetWindowsHookEx, the thread id.
When it is set to 0 then ..
'[in] Specifies the identifier of the thread with which the hook procedure is to be associated. If this parameter is zero, the hook procedure is associated with all existing threads running in the same desktop as the calling thread.'
That said, then like everything in Windows programming nothing is as what the documentation states, its as if the documentation is a wish-list Microsoft will like Windows to be when it grows up.
Actually even if you manage to get everything right you will see that the shell messages you will get will be VERY few compared to what the documentation states.
I am working on the same issue and when I get it going I will post the results here.
My program is a dll that hooks into a running instance of IE. It's worked fine for years.
Recently I dusted it off and ran it, but the last line below fails with hr = 0x80040154:
#import <mshtml.tlb> rename("value", "theValue") rename("event", "theEvent")
#import <shdocvw.dll>
// ....
SHDocVw::IShellWindowsPtr spSHWinds;
HRESULT hr = m_spSHWinds.CreateInstance(__uuidof(SHDocVw::ShellWindows));
Could it matter that IE7 has been replaced by IE8? Where else should I look?
I'm using VS2008, if that matters.
Edited to add
I don't see that it could be a 32/64 bit issue - it ran fine last year on this same machine. The only thing that's changed (as far as I have noticed) is the version of IE, from 7 to 8.
Note to the bounty hunters:
I only have access to this system for a few hours a day (around 0:00 EST), so you may not get quick responses to your suggestions, but I will look into them.
If you think there are things I should be checking (registry values, for example), be specific.
Edited to add:
I now see that the first time I call CreateInstance, it returns 0x80070002, not 0x80040154.
That's going to be very hard to diagnose. The ShellWindows coclass is special, its CLSID registry key is HKEY_CLASSES_ROOT\CLSID\{9BA05972-F6A8-11CF-A442-00A0C90A8F39}. When you look there, you'll see nothing useful registered there. The background story is that this is a leftover of an ill-fated attempt to make the Windows shell resemble a web browser. Still visible today, enumerating the shell windows returns both Windows Explorer and Internet Explorer instances.
The SysInternals' ProcMon utility is almost always the weapon of choice to debug 0x80040154 errors but it falls flat here. You can see it probing the registry, and not finding what it is looking for, but then the program knows how to load ieframe.dll anyway. This can only work by the operating system intercepting the CoCreateInstance() call. Which makes sense in general, considering the coclass enumerates shell windows.
All you got left is the trial-and-error approach. Reinstall IE first, OS next. Or to shove the machine out of a 4th story window before it eats too much of your valuable time.
I want to monitor when a key is changed/added/deleted to the registry whenever application is being installed or removed. I have tested the sample code from the msdn(link) and it works fine.
But the problem is that it does not tell me which key has actually been modified/added/deleted. How can i retrieve this information using c++?
There are only 3 ways, none of which is both easy and adequate:
RegNotifyChangeKeyValue:
Doesn't give you the info you need, but is very easy to use.
EVENT_TRACE_FLAG_REGISTRY which is part of Event Tracing for Windows
which is what ProcMon uses. It works well, but it's quite difficult to use.
I'm not sure exactly how to use it myself, but if I figure it out I'll post it here.
CmRegisterCallback:
Requires kernel-mode driver, which is a pain in 64-bit.
But it's the most perfect solution otherwise.
Unfortunately Event Tracing for Windows (EWT) does not allow to see full key path in the event. You get only a partial key name and a strange handle with is actually a key control block. It's not so simple to get information from this block.
Yes the process monitor uses EWT, but it does not use Windows Kernel Trace as a provider.
From what I understand, the output from the following script should include "Win32_PerfRawData_PerfDisk_PhysicalDisk" in Windows XP and higher, but it doesn't for me in Vista Business 32-bit Service Pack 2. Thus far I have been very unsuccessful googling for information about this performance class.
strComputer = "."
Set objWMIService=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & _
strComputer & "\root\cimv2")
For Each objclass in objWMIService.SubclassesOf()
Wscript.Echo objClass.Path_.Class
Next
Does this WMI class simply not exist in Vista? If it is just me, is there a way to fix WMI? I have already tried running winmgmt /resetrepository and winmgmt /resyncperf and neither helps.
Edit: Sorted and Edited Output
snip...
Win32_PerfFormattedData_NETFramework_NETCLRSecurity
Win32_PerfFormattedData_Outlook_Outlook
Win32_PerfFormattedData_PerfNet_Browser
Win32_PerfFormattedData_PerfNet_Redirector
snip...
Win32_PerfFormattedData_PerfDisk_* is missing.
Also tried lodctr /R. No help.
SOLVED
These counters can be disabled in the registry. Just set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Perfdisk\Performance\Disable Performance Counters to 0 and reboot.
http://blogs.technet.com/askperf/archive/2010/03/05/two-minute-drill-disabled-performance-counters-and-exctrlst-exe.aspx
Should be okay on Vista. the docs here state at the bottom of the page:
DLL: Wmicookr.dll on Windows Server 2003 and Windows XP, WmiPerfInst.dll on Windows Server 2008 and Windows Vista.
Can you check that the WmiPerfInst.dll DLL exists on your box?
Another things to try is to see if you can get stats from the corresponding RawData class? Vista appears to have changed the way in which raw data is translated to cooked data. My knowledge of that is pretty thin (based on a very cursory Google search) since I'm only involved in WMI on XP/Svr2k3/Svr2k8 - I didn't think anyone was actually using Vista :-)
And, if you're going to accept my answer even though it didn't help, at least let me plagiarise your solution :-)
These counters can be disabled in the registry. Just set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Perfdisk\Performance\Disable Performance Counters to 0 and reboot.
But seriously, thanks for that. At some point, we'll probably have to support post-Vista ourselves so it'll help us out to know this.
On Vista using IE8, I have an instance of IWebBrowser2, which I am using to obtain the current HTML document:
IWebBrowser2* browser;
CComPtr<IDispatch> disp;
HRESULT hr = browser->get_Document(&disp);
When this is executed by an Administrator, the call succeeds. However, when called by a regular user, the call returns an error code of "800706B5" ("The interface is unknown") despite the page being on a "Trusted Site" and "Protected Mode" being off.
This same code worked without problems on IE7 on Vista, and with IE8 on XP.
Does anyone know why this error might be occurring, and what I can do to resolve the issue? Running as administrator is less than ideal, and Jon Skeet is stumped by this one too :)
Update: the question seems to revolve around UAC: turning off UAC completely allows things to work for a regular user (though it's distinctly unsafe)
The error is occurring because on Vista, IE 8 runs in "low integrity" mode, whereas my test code, running as a normal user, runs at "medium integrity". The security model is designed so that code can send instructions to lower integrity components, but data cannot be read from "lower" to "higher" components by default.
More information is available in this document about How the Integrity Mechanism Is Implemented in Windows Vista
Was IE8 installed by the Administrator "For this user only"? I don't know why or if that would give this error, just a hunch.