I'm developing in windows with C/C++ and I want to know is it possible to get an apropriate \\.\SCSI device name by \\.\PhysicalDrive ?..
For example, it's wonderful to know how to get that \\.\PhysicalDrive0 is the same that \\.\SCSI0.
Look at the code which I posted in my answer to the question. The author of the question had changed the text of the question so many time and the last version of text clear nor really what the original problem was.
In the example, which C source code you can download here, I show how to get many kind of information about the local drive using different Windows API. The important thing which you need is that some name conversion like DeviceType and DeviceNumber (received by IOCTL_STORAGE_GET_DEVICE_NUMBER) like the following
DeviceType: 7, DeviceNumber: 5, PartitionNumber: 1
are unique in the operation system and can be used to identify the same devices. The reference to the statement you can find in the documentation of IOCTL_STORAGE_GET_DEVICE_NUMBER control code:
The values in the
STORAGE_DEVICE_NUMBER structure are
guaranteed to remain unchanged until
the device is removed or the system is
restarted. It is not guaranteed to be
persistent across device restarts or
system restarts.
In the way you can compare \\.\SCSI0 devices and \\.\PhysicalDrive0 and find out the correspondence.
Related
I am writing a program that is using a database library. The library provides me access to the file handle it uses to access my table. I've found a windows API that allows me to retrieve information about the file by handle but I've yet to find any means of determining access mode / permissions of that file. At this point I'm sure I could likely live without knowing this information but being the stubborn cuss that I am I'm not ready to let this one go. Obviously Windows knows this info - so the question is how can coax the info out of it?
The API function that I've found is: GetFileInformationByHandleEx and it takes me close to the watering hole but doesn't let me drink the water.
The reason that the file mode information is useful is that I need to modify the table header information. If the file is already in a proper mode then I won't have to close the table open the file modify the file close the file then re-open the table.
And yes, before I'm told of all the options available to me to achieve my goal - I'm not interested in those. I'm only interesting in the original question - how do I determine the mode of an already opened file. I look forward to any responses and I thank you in advance.
Thanks,
Robert Milligan
I don't know if there is a corresponding Win32 API for this, but if you really need it you can call NtQueryObject(ObjectBasicInformation).
OK. So I finally got this part all figured out - thanks to your direction, a lot of MSDN study and a LOT of trial and error.
There were a couple of tricky points to getting this all figured out.
1) The ACCESS_MASK certainly did not reflect the access modes as I expected. The documentation led me to expect the upper 4 bits to reflect the "GENERIC" modes that I opened the file with - wrong! Those show up in the Specific Rights section. Heck - I still don't have a clue when those upper 4 bits actually get used, but for this exercise I don't need to.
2) Once I got THAT clear in my mind I had to stumble across documentation that let me know that when I opened with GENERIC_READ that was translated into:
FILE_GENERIC_READ
which is made up of:
STANDARD_RIGHTS_READ |
FILE_READ_DATA |
FILE_READ_ATTRIBUTES |
FILE_READ_EA |
SYNCHRONIZE
Understanding this concept made all the rest of it fall into place. Now my understanding correlated with the information that Process Hacker was telling me.
3) I also had a serious error going from my UI to the code (read one constant misplaced), which once figured out made the whole world lay down before my feet.
This is great because I can now figure out what Access Modes were used when the file was opened. Original question answered!
Now I would like to be able to determine the "share" mode the file is in - if possible. Any ideas?
Thanks again for your help
Figured it out maybe? From my reading of the docs, it seems you might be able to discern the original "share mode" of an open handle by calling ReOpenFile with dwDesiredAccess of 0 and dwShareMode for one (or more?) of the modes to query, i.e. FILE_SHARE_DELETE, FILE_SHARE_READ, FILE_SHARE_WRITE. If ReOpenFile returns a valid handle--which you can then close/dispose--then that sharing mode was present on the original file?
Source:
"If dwDesiredAccess is zero (0), the application can query device attributes without accessing the device. This is useful if an application wants to determine the size of a floppy disk drive and the formats it supports without requiring a floppy in the drive."https://learn.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-reopenfile
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 have an application, that needs to talk to a piece of custom hardware. I know roughly the format that the driver will register a symbolic name, however based on some physical switches on the card, the card will have a somewhat dynamic name. My question is is there way to find the registered symbolic name, or find the driver and create the symbolic name.
My application use the symbolic name for operations like CreateFile(), WriteFile(), etc.
Update
The driver is PNP, so it really only makes the one subkey under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\V70QT\, and I will have potentially more than 1 card. I thought for a second there, that I could use this registry key
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\V70QT\Enum]
"Count"=dword:00000001
"NextInstance"=dword:00000001
"0"="PCI\\VEN_10B5&DEV_2021&SUBSYS_202110B5&REV_03\\4&33c89357&0&08F0"
Because the symbolic key name gets built in a format similar to V70QTX_Y, where X is the card ID (switches on hardware), and Y is the channel (irrelevant here). I thought I could build the name up using the "NextInstance" value however that will not work, as the card could have a switch ID of like 4, and be the first instance.
If your driver shows up under [HKLM\System\CurrentControlSet\Services], it would simply be a matter of enumerating the subkeys there.
I'll try to keep this as short as possible.
I have an app that has worked for years with a single mouse input. I am looking to incorporate the ability for my users to use other forms of input, such as interactive projectors, touch devices, or pretty much anything that provides WM_INPUT messages when you register for them.
The general idea I had was I would have a list of Vendor IDs and/or Product IDs that I would handle with Raw Input (which provides VID/PID, device handle and other information) for each message (WM_INPUT) received. Any devices that are not handled in the Raw Input code would be handled in the Mouse Input code (WM_MOUSEMOVE, WM_LBUTTONDOWN, WM_RBUTTONDOWN, etc).
Ideally, I would be able to leave all of my Mouse Input code as is, or close to it. This way, if a user plugs in two mice, or a mouse and an unsupported pointing device (meaning my Raw Input code doesn't handle it based on VID/PID) the devices would both use the same system cursor. Any device that is known by my Raw Input code would be given separate cursors that exist only within my app.
The problem is simple: Mouse Input does not provide any information about the source of the message (such as WM_MOUSEMOVE, etc). Knowing that the message originated from touch helps (I have this implemented) but is definitely not enough. I need some kind of unique identifier. If I could know the source of the Mouse Input, I could only handle Mouse Input from devices that aren't on my list of known devices, and I could only handle Raw Input that are on my list of known devices.
Unfortunately, I cannot seem to find a way to achieve this.
Any ideas?
Thanks for your time sorry for the lengthy post.
TL;DR - Can you identify the source of Mouse Input (not Raw Input) in Windows? Determining whether or not the source is touch is not enough information, I need some kind of unique identifier.
Mouse Input - http://msdn.microsoft.com/en-us/library/windows/desktop/ff468877(v=vs.85).aspx
Raw Input - http://msdn.microsoft.com/en-us/library/windows/desktop/ms645536(v=vs.85).aspx
I don't know of any API for getting some sort of device id after the fact.
You could use the fact that WM_INPUT messages come before all other input messages, and when you handle WM_INPUT you could use GetRawInputDeviceInfo and a hash of the name returned by RIDI_DEVICENAME to use as a unique id. Or, you might be able to use the hDevice member of the RAWINPUTHEADER structure.
edit2: The answer to this question is "Not possible", you can't do it. Don't bother trying, but if you do and I'm wrong please explain. The fact of the matter is you can't rely on Windows to provide messages in any particular order consistently, which is what I was attempting to do. This bit me big time. Either use raw input (WM_INPUT) or use mouse messages (wm_mouse) don't try to combine the two somehow.
I never really got the answer I wanted, but I got something that works so I thought it was worth sharing.
I am working on a huge assumption, as I can't find any documentation from Windows to support this assumption (and probably wouldn't really even trust it if I found documentation from windows). To my understanding, when a mouse event is generated at the lowest level it comes through the system as a raw input message first (WM_INPUT). After the WM_INPUT message is posted, the OS gets the message and applies the ballistics and whatever else it does before a WM_*MOUSE* message is posted. The huge assumption is that this process is serial in that it is always 1 WM_INPUT message followed by 1 WM_*MOUSE* message in the queue.
With this assumption I am working with the following:
When an input message is received, store all relevant information about the source device as the "current input information"
When a mouse message is received, process it using the "current input information" as the source of the mouse message
This allows me to use n inputs in my application independently.
I'd also like to add that per Brandon's suggestion I am using the hDevice member of the RAWINPUTHEADER structure to uniquely identify each input. Since a unique device can have multiple inputs, I have yet to come up with a good way of uniquely identifying each device. VID/PID doesn't work because you can have 2 of the exact same device with multiple inputs each plugged in. I'm still working on this, see Windows HID Device Name Format
Please let me know if anyone would like me to elaborate!
edit: not marking this as the answer since I believe the correct answer is "Not possible"
I need to list all open handles in current process.
Since i could not find any function like "EnumHandles", I was thinking of making a loop from 0 to 1000. The question is how i can retrieve the name of each handle?
I am using c++ and the OS is Win7 32-bit
EDIT:
The handle I need name of is a Mutex.
By comparing the name of the mutex, i want to get the handle id
I seem to have found solution using OpenMutex, but i don't know what to pass on 3rd parameter,
I believe you have to use the NTDLL.DLL. To my knowledge this is what all tools monitoring processes, handles and other system information, have to use in the end, under Windows. I used it in a small Win32 tool, however never had to list handles.
Check here for a good intro of that library and related to your question. http://forum.sysinternals.com/howto-enumerate-handles_topic18892.html
Also the GetObjectName function in the first post of http://forum.sysinternals.com/enumerate-opened-files_topic3577.html
Accessing this kind of information in Windows may seem to be a lot of work and looks frightening because Microsoft does not want to support it, but you will see that when the 'easy' API is not giving you what you need, you have to dig to NTDLL. This is what tools like ProcessExplorer use in the end. It is not so hard to use: load the DLL, get the right function pointers to fill the structs that you declare yourself with what you will find on the net.