I'm going to be the good boy for this one... So...!
It's in the local registry or local user files (C:/Users)!
I wouldn't say this is harware coded as what they most often use there is the unique ID of a grasphics cared or the MAC address burned into the network card.
You need to check local registry files:
This is the easiest place for a program to write data without needing administrator rights. When the second user launches the app, it checks that same location in
their registry, finds nothing, and concludes the software isn't licensed for them.
- Log in as the working user.
- Open regedit and navigate to HKEY_CURRENT_USER\Software. Find the key for the application.
- Look for any subkeys or values named "License," "Serial," "Activation," or similar.
- Export this key (.reg file) and, as the non-working user, you could try importing it
2:
Instead of the registry, the application may have saved a license or activation file inside a folder like C:\Users\OriginalUser\AppData\Local\AppName or C:\Users\OriginalUser\Documents\AppName. The second user has no access to this folder, so the application can't validate its license.
- Use ProcMon and filter for file operations. When the license error appears, stop the capture.
- Look for attempts to read files with names like license, .lic, .dat, or activation that result in "PATH NOT FOUND" or "ACCESS DENIED". This will tell you exactly where the application is looking for its license file.
3:
And now... For AI explanation time on finding those nasty bits!
Process Monitor is a free and powerful tool from Microsoft that shows you all the file system and registry activity on your computer in real-time. It's the perfect detective tool for this kind of problem because it will show us exactly what the application is trying to do and where it's failing.
You can download it directly from Microsoft:
You must be registered to see the links
The Strategy: Capture, Compare, and Conquer
Our plan is simple:
- Capture a "Good" Trace: Run ProcMon as the Working User to see what a successful launch looks like. This is our baseline.
- Capture a "Bad" Trace: Run ProcMon as the Failing User to see where the launch goes wrong.
- Compare the Traces: Find the key differences—specifically, the "ACCESS DENIED" and "NAME NOT FOUND" errors in the bad trace that don't appear in the good one.
Step 1: Capture the "Good" Trace (Working User)
First, log in to the Windows account where the software
works correctly.
- Launch ProcMon: Run Procmon.exe. You will need to agree to the license agreement the first time. It will immediately start capturing everything happening on your system, which is overwhelming.
- Stop the Capture: Immediately stop the flood of information by clicking the Magnifying Glass icon (or pressing Ctrl+E). The icon will now have a red 'X' over it.
- Clear the Display: Clear the captured events by clicking the Eraser icon (or pressing Ctrl+X).
- Set Up the Filter:We only care about our specific application.
- Go to Filter > Filter... (or press Ctrl+L).
- Create a filter for the application's executable name (e.g., AppName.exe).
- Set the filter as: Process Name | is | AppName.exe | Include.
- Click Add, then Apply, then OK.
- Start Capturing and Launch the App:
- Click the Magnifying Glass icon again to start capturing.
- Immediately launch your problematic application.
- Wait for it to fully open and run correctly.
- Once it's running, go back to ProcMon and click the Magnifying Glass icon one last time to stop capturing.
- Save the Good Trace:
- Go to File > Save....
- Choose "All events" and select the format "PML (Procmon Logfile)".
- Save the file to a location accessible by both users, like C:\Temp\GoodTrace.PML.
Step 2: Capture the "Bad" Trace (Failing User)
Now, log out and log in to the Windows account where the software
fails.
- Launch ProcMonand repeat the exact same steps as above:
- Stop capture (Ctrl+E).
- Clear display (Ctrl+X).
- Set the exact same filter for the application's Process Name.
- Start Capturing and Recreate the Failure:
- Start capture (Ctrl+E).
- Try to launch the application.
- Wait for it to fail (either it closes, times out, or shows the license error).
- Once it has failed, stop the capture (Ctrl+E).
- Save the Bad Trace:
- Go to File > Save... and save this trace as C:\Temp\BadTrace.PML.
Step 3: Analyze and Find the Culprit (Failing User)
You are now ready to find the problem. Open the BadTrace.PML file you just created. The answer is almost certainly in here.
How to Find the Smoking Gun
You are looking for events that show the application trying to access something and failing. The most common errors are:
- NAME NOT FOUND: The app looked for a registry key or file, and it doesn't exist. This is the most likely culprit for license issues or failures to launch.
- ACCESS DENIED: The app found the file/key but doesn't have permission to read or write to it. This is common if it's trying to access another user's profile folder.
- PATH NOT FOUND: The folder in a file path doesn't exist.
Here’s how to filter for them:
- Open the Filter Menu: Go to Filter > Filter... (Ctrl+L).
- Add a Filter for Failures:You already have the Process Name filter. Now add another one:
- Set the new filter as: Result | is | NAME NOT FOUND | Include.
- Click Add.
- Add another for ACCESS DENIED the same way.
- Your filter list should now look like this:
- Click Apply and OK.
Your ProcMon window will now only show you the moments where the application failed.
Interpreting the Results
- If you see NAME NOT FOUND under HKCU:
- Path: HKCU\Software\VendorName\AppName\License
- Meaning: The application is looking for a license or setting in the current user's registry (HKCU is HKEY_CURRENT_USER). It found nothing. This confirms the settings were only saved for the original user.
- If you see ACCESS DENIED on a file path:
- Path: C:\Users\OriginalUser\AppData\Local\AppName\config.xml
- Meaning: The application has a hardcoded path to the original user's profile folder. The new user is not allowed to access it, so the operation fails.
By looking at the paths in this filtered view, you will have your answer. It will point directly to the registry key or file path that is causing the application to fail. You can then compare this to the GoodTrace.PML (by opening it and applying the same filters) to confirm that these errors do not happen for the working user.