I'd like to get the processor id without using WMI.
But if I try to get it using CPUID with EAX=3, I get an empty result.
How does WMI get the ProcessorId? And is there a way to get it without using WMI?
I found it out by myself, after looking at a cpuid dump.
It looks like WMI is creating the processor id by just combining EDX+EAX from the results of CPUID with EAX=1.
I thought that id from WMI was a unique serial number, but apparently it is not!
Related
I am developing a tool that displays a status about various hardware components on a system we use at work. Currently, we have 16 touch screen monitors (all by 3M) plugged in to a Windows 10 box. I need to verify that any given monitor has an associated touch screen recognized by windows. This is to assess the system for any hardware malfunctions i.e. bad cable, bad USB port, bad Monitor, etc. We see this more than we would like to admit, usually where a monitor's display will be working fine but the USB controller on either end drops out and needs to be reset by unplugging/plugging back in
Unfortunately my code posting will be limited due to work constraints.
I can enumerate all of the monitors plugged in to the system via winapi's EnumDisplayDevices and EnumerateDisplayMonitors. I am able to build a list of all the HID touch screen devices using HIDApi.
From here I have no direction on where to go to link these two things together, if it is even possible. My first thought was the HID device information should have some sort of identifier shared by the results of calling the EnumDisplayDevices and EnumerateDisplayMonitors, but I have not found this to be the case. Another possibility would be to compare the coordinates/size of a monitor to a region that one of the touch controllers is responsible for. Again, not sure if that is possible.
In short, is there a way to associate a Touch device with it's corresponding monitor via c++?
I think you were just lucky that this driver suffix matched your monitor configuration. In my Windows 10 multi-monitor setup I get wrong displays when I look them up with this number in the driver entry as you described.
A reliable way for associating a HID device with a display seems to be:
Call GetRawInputDeviceList() to obtain the HID devices
Call GetRawInputDeviceInfo() with RIDI_DEVICEINFO to determine Usage and UsagePage
Call GetRawInputDeviceInfo() with RIDI_DEVICENAME to get a device string in the form \\\\?\\HID#VID_0EEF&PID_7200&Col01#6&152cc7f9&1&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Query the registry for the mapping table at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Wisp\Pen\Digimon and look up the display device name. In my case the HID names are all prefixed with 20- there but the remaining part seems to match the name queried by GetRawInputDeviceInfo() exactly. As a fallback method in case there is no match, I also parse the middle part as Clay Brooks described in his answer.
Call EnumDisplayDevices() with a null pointer for lpDevice and 0 for dwFlags in a loop until the function returns zero.
Within each loop iteration, call EnumDisplayDevices() again with the current device as lpDevice and EDD_GET_DEVICE_INTERFACE_NAME for dwFlags and observe that it returns a DeviceID in the form \\\\?\\DISPLAY#ELO2243#5&607b301&0&UID24833#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}
Loop until a HID <-> display match is found and take the DeviceName returned by the "outer" EnumDisplayDevices() call which should be something like \\.\DISPLAY3
After the suggestions in the comments and looking deeper into the registry, I've found a way to link Touch controllers to a monitor.
Using HIDApi, you can poll the system and find a list of all the Touch Controllers you need to monitor. I filtered by the VID of the monitors we are using. A sample return value for the path looks something like this:
"\\?\hid#vid_0596&pid_0520&col02#8&33d9e616&0&0001#{4d1e55b2-f16f-11cf-88cb-001111000030}"
The bold part can be used to link to the entries in HKLM/Software/Microsoft/Wisp/Pen/Digimon. An example entry is this:
"\\?\HID#VID_0596&PID_0520&Col03#8&33d9e616&0&0002#{4d1e55b2-f16f-11cf-88cb-001111000030}" "\\?\DISPLAY#MSY1C2B#7&1083071f&0&UID524#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}"
The first bold matches the data found through HIDApi and the second set of bolding, the monitor name and a UID, is listed in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY. Under here you can use the combination of monitor name and UID to find the Driver entry. Below is a sample driver entry:
{4d36e96e-e325-11ce-bfc1-08002be10318}\0010
The last bold number can then be used to match up with a DeviceID returned from EnumDisplayDevices(). Below is a sample DeviceID:
"MONITOR\MSY1C2B\{4d36e96e-e325-11ce-bfc1-08002be10318}\0010".
Then you can use this bolded section to match up to names of monitors returned from EnumDisplayMonitors().
I'm making a program, to stop pirating i'm adding a hwid lock. I want to use the output of the wmic command wmic csproduct get uuid. However I am not sure how to set its output as a variable.
I believe this is what you are looking for:
HW_PROFILE_INFO hwProfileInfo;
if (GetCurrentHwProfile(&hwProfileInfo))
printf("HWID: %s\n", hwProfileInfo.szHwProfileGuid);
There is no guarantee this value won't change though. This is the GUID of current hardware profile on Windows, but it can be set up to have more than one of those.
I believe this GUID will change automatically if there's a drastic hardware change, like replacing the motherboard. Though this would also deactivate the Windows license, so I suppose Windows too rely on hardware profile to validate it's licensing.
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
I would like to make wmi query in cs to trigger NDIS OIDs.
For example, to check hardware status (OID_GEN_HARDWARE_STATUS) I can use ManagementObjectSearcher("root\\WMI", "SELECT * FROM MSNDIS_HardwareStatus")
I need to make some other requests, but I cannot find any way to find wmi class name for given OID (let's say it's OID_802_3_RCV_OVERRUN, there is no any obvious relation like OID_GEN_HARDWARE_STATUS -> MSNDIS_HardwareStatus for it, at least I have not found one).
How do I find relations between wmi class name and NDIS OIDs? Is there any documentation for it?
The specific example you cite, OID_802_3_RCV_OVERRUN, does not have a corresponding WMI class. Here's one way to prove that, if you're comfortable using a kernel debugger.
Run the kernel debugger command !ndiskd.miniport -wmi <someHandle>
Search the text output for "OID_802_3_RCV_OVERRUN"
There's no matches, so the miniport does not expose that OID to WMI
If you'd rather not use a kernel debugger, or if you just want to see a few more examples, here's an article I wrote on how to inspect the relationship between WMI classes and OIDs.
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.