I'm trying to write a script that incorporates a retrieved Drive Serial Number for a report. So far I've just been trying to get a WMI call or really anything to even retrieve it in the first place
WMIC PATH CIM_PhysicalMedia
works on some computers but not in the WinPE environment I need it to work on. I keep getting: Invalid XML Content.
Every command I try, I use both CIM_PhysicalMedia and Win32_PhysicalMedia and neither work when it doesn't work.
What's funny is, the system it works on is Windows 7 Pro but it doesn't work on another PC with the same OS! Am I missing a dll or something?
Please help! Again this is supposed to work in a WinPE environment. I do not know the version but I do know that WMIC works normally.
Please help!!
PS I have experience with simple WMI calls like wmic bios get serialnumber and the like but I have never messed with anything this apparently complex.
I have not tested on Windows PE environment. Give it a try. Let me know if it works or not. Run below mentioned using powershell.
Get-WmiObject -Class Win32_DiskDrive | Select serialNumber
Related
I'm writing a program in C++ and at one point I want to open a file with a certain program (either Libreoffice or Word, depending on what is installed on the pc). For that I need to check which program is installed on the pc first.
I'm usually using linux and for that I have found
if (!system("which libreoffice --writer > /dev/null 2>&1")) {
const char* command = "libreoffice --writer myfile.rtf &";
system(command);
}
which works perfectly.
However, I cannot figure out how to do the same for Windows (the program is meant to run on a Windows pc).
I know that I can query if a program is installed in Windows using where -command, however apparently I don't quite understand how to use it for I cannot get it to work for me.
Help would be very appreciated.
You do not need to check which program is installed on this PC before executing a data file on Windows.
You can use ShellExecute directly on a data file, and the system will find the program that has been associated with that file type, and execute it appropriately.
Depending on your needs, you may prefer to use ShellExecuteEx instead. In particular, if you want to find when the child process finishes execution (or similar), ShellExecuteEx gives you a handle to the child process, which ShellExecute does not.
If you really want to find the executable associated with a data file (even though it's unnecessary for the case you've cited), you can use FindExecutable to do that.
Hello want to use wmic to unistall a program the problem is that the program is stored in:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
And wmic can only view by default:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall
Can you find a way to unistall apps in:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
using wmic?
I have seen some posts regarding this problem:
Also found this might be helpfull:
I really need to use wmic for uninstall the program can anyone help me?
Can anyone create a small function in cpp to set WMIC on HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall as default?
I know it is hard, any help would be great!!!
Doing what you are asking for is documented under Requesting WMI Data on a 64-bit Platform:
C++ applications can use the IWbemContext interface with IWbemServices::ExecMethod to communicate the use of a nondefault provider to WMI.
I am having a problem with calling the function MsiOpenDatabase (https://msdn.microsoft.com/en-us/library/aa370338(v=vs.85).aspx) from inside a program when I choose to "run as administrator". When I run it under an admin account but without explicitly starting the executable as elevated it all works just fine. This indicates that the path to MSI file etc should be correct.
So, when running elevated the MsiOpenDatabase() I get an error code of 110 (0x6e).
I have tried to call MsiGetLastErrorRecord as explained here (https://msdn.microsoft.com/en-us/library/aa370124(v=vs.85).aspx) but nothing happens when I try to print the code in a message box. It simply doesn't get there.
I do not have Visual studio for debuggning on the target machine, so debugging is a bit of a pain.
Target machine is Windows 7 x64. Application is 32-bit.
But just the pure fact that it works un-elevated but fails when run as an administrator...it feels like there should be some kind of answer to this which can be derived from this fact perhaps?
Thankful for any help!
EDIT:
I finally solved it!
Apparently I had to go to the network share where the MSI file is located (which I am trying to call MsiOpenDatabase on) and right cklick on a file there and choose "run as administrator" because then and only then did I get a UAC dialog box asking for credentials (I mean I was able to open Windows Explorer as admin and navigate to the network share without problem so I never thought that it would be what would give me these peoblems). After haing done that I was able to run my application and it did no longer fail on any MsiOpenDatabase call.
But, why must I do this procedure to get access to run file on a network share since I already had access (execute rights) with the same user but when not elevated? How come Windows needs to ask the same user for credentials if it is already running elevated on the very same account that already has access to the network share? Seems strange to me, but I suppose I am missing some crucial part?
SAMPLE CODE
LPCTSTR szPersist = MSIDBOPEN_READONLY;
MSIHANDLE handleDB;
UINT result = MsiOpenDatabase(strPath, szPersist, &handleDB); // strPath is something like _T("\\server\MSI\Setup.msi");
result variable has value 110 when this error occurrs as explained above and keep the part in the update section in mind. I find it strange, but perhaps someone knows UAC better than me and why I have to provide credentials again by going to a file on the netowrk share and choose to run as admin to get it working (since I have already provided credentials as non-admin with the same account earlier at that very same network share location)?
This is standard UAC behavior since Windows Vista and is not related to MSI at all. Do a google search for "uac network drives".
You should be closing your MSI handles though as I commented above. Use PMSIHANDLE instead of MSIHANDLE.
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.
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.