Generating a machine ID for post-mortem analysis
In one of the projects I'm working on, we use minidumps to do post-mortem analysis of crashes (which is very helpful, if I might say - If you're not doing it yet, do it!), where the client is presented with the option to upload the minidumps after a crash to our central server. For large scale deployment, I'd ideally want to associate this in the database with a machine-specific ID, other than the machine's specs, which would be useful in cases where I want to now if this problem is occuring a lot of times on few machines. Ideally, I'd want this ID to change when the machine setup (a vague word for now, that's a mix of HW, SW and drivers) changes: I don't want machine A running XP have its dumps treated the same as machine A running Vista (Or a quad / double core, ATI Vs. Nvidia, etc.). I'd also like this to be one-way, in order not to pose privacy issues. Brainstorming so far, I believe it'd be best to have 4 IDs: HW ID, Drivers ID, SW (OS, dx et al), and a grand-unified ID that's a function of the previous three. The application I'm working on also generates a couple of "runtime-environment" hashes, but these are very app specific. For the previous four, what're your ideas? I'd love to have a peer-reviewed and agreed on definition (and I'm willing to contribute any code I work on under the MIT license. Hopefully someone will find it helpful).
You should be able to have a thorough profile in general, but unrelated to the machine ID. For the machine ID itself, you can record the installation timestamp, concatenated with a random number (just in case somebody was installing that very same millisecond).
This may cause a problem if they wipe and reinstall everything though. You could check serial numbers, if available.
It's important (of course) to make sure you get permission for anonymous statistics.
Also, you could allow for a registered username or email address if they opt-in for this, and that should cover most reinstalls. Even if it's gibberish, it's likely unique gibberish, and coupled with other information it creates identifiable information.
Lastly, as long as it's calling home anyways, you could have a central server provide a uid and receive updated profile information.
This may cause a problem if they wipe and reinstall everything though. You could check serial numbers, if available.
It's important (of course) to make sure you get permission for anonymous statistics.
Also, you could allow for a registered username or email address if they opt-in for this, and that should cover most reinstalls. Even if it's gibberish, it's likely unique gibberish, and coupled with other information it creates identifiable information.
Lastly, as long as it's calling home anyways, you could have a central server provide a uid and receive updated profile information.
I'm familiar with the UUID and GUID concepts. What I'm trying to achieve is a larger scale concept: The machine ID should be unique for this hardware configuration, whether I use it to debug App X or you use it to debug App Y. Maybe you and I will sometime run some analysis tool and find something related to crashes on a specific machine, or in a more likely world, we'll find crashes for all our apps that use component X with machine Y. The drivers ID should also be the same: a hash of all the driver versions of a machine. This'll make identifying troublesome configurations easier. The software ID should serve a similar purpose.
Hi
Why not generating ID on the database server when the first crash is reported ?
Here's how I see the problem :
- The first time the user report a crash he doesn't have an ID, so your crash server generate an ID for your user. The user backup this ID and the next time he reports a crash he uses this ID.
- In the case your user uninstall / reinstall your app you can save this ID in the registry or something like that.
- The user config changed, you log every hardware / software information in your database and you have to check that every entries have the same configuration.
Why not generating ID on the database server when the first crash is reported ?
Here's how I see the problem :
- The first time the user report a crash he doesn't have an ID, so your crash server generate an ID for your user. The user backup this ID and the next time he reports a crash he uses this ID.
- In the case your user uninstall / reinstall your app you can save this ID in the registry or something like that.
- The user config changed, you log every hardware / software information in your database and you have to check that every entries have the same configuration.
What abt the scenario when the user formats his PC, then installs the app again? That's why I want to have several IDs, each tied to a unique aspect of the machine state.
So when the user uninstall the application, erase all reference to his previous ID.
You can also make your ID with the version of the dll/application you are using (opengl.dll, Directx.dll, fmod.dll, windows version...) as "primary keys" in your database design and not only using a single field as an ID. So if the user formats his PC and not updating his drivers you have a new ID...
You can also make your ID with the version of the dll/application you are using (opengl.dll, Directx.dll, fmod.dll, windows version...) as "primary keys" in your database design and not only using a single field as an ID. So if the user formats his PC and not updating his drivers you have a new ID...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement