DIDEVICEINSTANCE guidInstance and guidProduct change on same device - windows

I am using DirectInput8 in a project at work that monitors various components of the pc. To monitor joysticks we use DirectInput8. The data is retrieved by enumerating all joysticks with DI8DEVCLASS_GAMECTRL as the type and DIEDFL_ATTACHEDONLY as a flag. Recently it was brought to my attention that we were having multiple joysticks showing up. First I looked at the xml file we store the components in between reboots. There were two entries for the joysticks, Logitech Extreme 3d pro, and each had a unique product guid. I backed the file up and removed it, effectively forcing a rescan of the machine next time the app started after I rebooted the machine. I was able to get the same problem to occur and logged out the guids and they are different for each. The system only has a single joystick plugged in however it plugs in through a usb hub. Is the hub affecting the guids I am seeing? I could also only get this to occur maybe 1 out of 5 attempts.
Example:
Joystick Product GUID: 3C6A972000000000504944564944
Joystick Instance GUID: 3C6A972097C11E3800144455354
Joystick Product GUID: DA83AFB000000000504944564944
Joystick Instance GUID: DA83AFB0D7B211E2800144455354

Had a similar issue... I just exported the DirectInput registry settings for the VID/PIDs I wanted to replicate GUIDs across machines.
So, in regedit navigate to:
[HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_[Whatever]&PID_[Whatever]\
Right click, choose Export to create the .reg file, the move it to the machine you want and double click.

This was a pain to find but after watching our testers I found they were logging into multiple user accounts and the GUID returned was different per user which is what caused the problem, would be nice if the documentation would be updated to reflect this.

I'm having the exact same problem as the original poster. To clarify his answer, its the instance GUID that is different for each user. And here is the MSDN documentation that incorrectly asserts that the InstanceGUID should stay the same on a given computer. Without someone from Mircosoft weighing in I don't know that I'll ever know the answer why this is - is it a bug or is the documentation incorrect.
The bottom line is you'll have a heck of a time sharing keybindings for a joystick among multiple users without a solution to this problem, which is my situation.

Related

Once windows installation is complete. Does windows ever try to look for change in unique ID of motherboard or processor ID

Let Say there are two identical systems. One of which has licence version of windows and I am ghosting entire drive into second computer's hdd. will windows ever come two know?
If that system is not connected to internet ?
Is CPU_ID unique Identifier or is it a cpu product ID.
I know mac address is unique in a system but I want to dig deeper in finding unique identifiers of system.
Take a look at this.
What should be the unique ID of a machine? Its motherboard ID? Windows Product ID?
I am working on visual C#.
The Kernel is compiled with specific drivers and the Kernel knows all the information about the hardware including their firmware version and hardware Ids. (one of the reason for BSOD)
If you install a windows and change the HDD to another same set-up, windows might try to repair and work. However if you have TPM chip and Bitlocker enabled, windows will ask you for the BitLocker recover key as soon as you've changed the hardware setup. That's because windows kernel knows each hardware and their ID's and therefor changes in them.
In order to answer you intended question, don't bother trying to prevent privacy you will never succeed and there will be someone to crack it. Instead spend that time on your actual product and marketing. People who want's to steal, they will steal anyway or won't use. Spend your time for those who would want to buy your product.
Having said that, move important code to web service if you really that much worried.

How do demo-versions know the test-time is over after re-installing?

How do applications like CloneDVD2 or AnyDVD know that the free phase is over, even if the application was uninstalled and then re-installed? Those applications don't require the user to login so that they could identify the user again.
Also on deinstalling them a window pops up asking whether the "registration files" should be kept or not. Even if they are not kept, the re-installed application knows the demo-time is over.
How is that technically realized?
Could be everything...
You might reverse the algorithm to find out.
But to name an example:
It's possible to generate a hash, based on unique hardware identifiers, of your hardware configuration and send that over the internet to a database.
If your hash exists over there, the software knows you ran it before.
An other option is leaving tracking information inside of your OS. So the checkbox: delete register information, isn't deleting everything.
To test:
1) Switch GPU or CPU :P
2) Format & Reinstall computer

Damaged files on Windows Mobile

I'm in need of help. The situation is the following:
We have a software that runs on Windows Mobile 5 and 6. It is deployed in around 15 cities on different devices (Motorola MC35, MC55, MC65, MC75, MC75A, ES400). It works perfectly fine everywhere except in one city. They have MC75A devices and every once in a while we get a helpdesk about our software disappearing from the device.
The most interesting part is when we log in to check the device, all we can see is a damaged/corrupted file system and the OS, which is set back to default.
We tried to reconstruct the problem here at our company, but we find it impossible. I'm wondering if anyone has ever bumped into this.
I'm gonna attach two images of the corrupted file system.
We use custom windows settings and AppCenter to protect the operating system from our customers. (They shouldn't be able to modify any settings on their own).
In general such corruption happens when the driver is interupted saving changes to the file system.
That can happen, for example, when a high priority thread consumes all cpu times.
It may also happen, when the device is hard reset, for example by taking the battery out during thed river is writing to the file system.
A low battery normally cannot result in that corruption:
a) as the device shuts down itslef with critcal battery power
and
b) the file system is in flash RAM (in contrast to Windows Mobile 2003 and before) and does not need battery power to hold data.
It is also possible that there is a bad behaving process doing these corruptions.
As you say you see this only in one city: What is the main difference with the devices there?
Are others also using the same device? Maybe the device series itslef or there firmware is faulty (contact symbol/motorola for new firmware or patches to the 'disk' driver)
Are the users in that area doing special things to the devices that others do not? For example remove the battery when they mean the device does not react?
Is the MC75A used in other areas and there it does not show the corruption?
You see, you have some more items to examine a rule for the corruption?

how can programs tell if you've used them past them demo period?

On certain programs you can run them on a demo period for say 'ten tasks' or '5 hours' before you need to decide to purchase them to keep using them, but if you delete and uninstall the program then reinstall it, it knows that its been previously installed and wont let you run the demo again.
How does it do this ? When you download it does it send a identifiing number (ip ?) to the cdn to let it know youve downloaded it before, or when the program itself installed does it check to see traces of previous installation ?
Most "demo" software does this by a feature borrowed from malware: Incomplete deinstallation. A file or registry key belonging to the software is not removed on deinstallation. On reinstallation the software sees the remainder and can act on it.
Often-used hiding places for such a remainder were the system directory (before UAC arrived), but many register some class GUID - nobody I know of has a real overview of which classes in the registry are or are not genuine.
There are many ways this can be implemented.
The easiest way to implement (and also the easiest way to bypass)
On first run, create a registry (or text file) entry somewhere
Add 1 to the counter every time the task (or the app) is run
Do not include this file/registry in the installer app (so it will persist after uninstallation)
If at any time the count is too high, notify the user that the trial has expired.
Using image diff tools this method is pretty easy to identify and overcome.
The hardest method to overcome or bypass is to use a server. On the first run, generate a hash code based on the users computer name, drive serial number, etc, and post this to your server. The server then tracks this as a unique installation, and allows the app to run. Each time you run the app, you update the server. This way, the user cannot find the breadcrumbs and delete them, since they are on your server. The down side, is that this method will require an Internet connection.
There are probably much more sophisticated methods to achieve this result, but the above are both implementations I've run across.
My software drops breadcrumbs within the users system which is used to check for previous installations. This is a little harder to get around (assuming you don't know what you are looking for, or where) than an internet check against your IP. As you can always spoof your connection information, or just disconnect from the internet while installing.

Question regarding guidInstance in DirectInput library; also deals with enumeration of devices

Regarding guidInstance in DIDEVICEINSTANCE
Microsoft says:
Unique identifier for the instance of the device. An application can save the instance globally unique identifier (GUID) into a configuration file and use it at a later time. Instance GUIDs are specific to a particular computer. An instance GUID obtained from one computer is unrelated to instance GUIDs on another.
So, if I connect my device to the computer and my program does enumeration and finds the guid, do I ever have to enumerate again? Even if the user plugs and unplugs the device. If another device of the same type is plugged in, does it still recognize that the second device is not the same as the first and therefore requires a different guid? Should I just renumerate all the interfaces all the time my program runs to find my device or is once enough for a given pc?
Thanks.
I'm actually trying to solve a similar problem. According to the MSDN here, it looks like InstanceGUID is supposed to always be the same on the same computer. I've verified that if I unplug my USB device and plug it into a different port, it does indeed keep the same Instance GUID. However, if a different user logs into the same PC, DirectInput shows the same device having a different InstanceGUID!! I can't find any acknowledgement from Microsoft that this is a known problem.
So, I can partially answer your question. If you have two identical devices, you will get different InstanceGUIDs, and identical ProductGUIDs. Those InstanceGUIDs will stay consistent if you unplug your devices and move them to different USB ports. HOWEVER you will get different InstanceGUIDs if a different user logs in. At least I can verify that this is an issue on Windows 7 64bit.
The InstanceGuid will always be a unique identifier for every device plugged in - but if you remove the installation information (e.g. uninstalling a usb device) you also lose that InstanceGuid. The device will get some new unpredictable Guid when plugged in again.
The ProductGuid will always be the same for one device, since it's stored in the devices USB HID chip. It may happen though that two devices of the exact same type have the same ProductGuid. If they do, you can only identify them by their InstanceGuid (which may become invalid in some cases, as written above...).

Resources