Forum Discussion
System environment variable Patch and registry
Ok, here's details:
here's file location C:\Windows\test\toy.exe
this my registry key
HKEY_CLASSES_ROOT\DesktopBackground\Shell\toy\command @="toy"
this is system variable Path: C:\Windows\test;C:\Windows\system32;C:\Windows;..... and so on
when I open command prompt (let say on desktop location) type: toy and enter, it works, so the path C:\Windows\test works, but the same command from registry doesn't. So, in this case path C:\Windows\test doesn't work and it drives me crazy. I don't understand at all how this is possible.
In this case what you could do is:
1- You verify the integrity of the application files, from your main repository folder. Not the HKEY_LOCAL
...at this point I am not sure of what the current problem exactly however, you can run a debug on your application to check files integrity.
x- You can use a checksum validation to verify whether the application function and logic follow the proper path in order to reach the consensus.
xx- If nothing is found, you should try a different checksum parity bytes or check in the
https://learn.microsoft.com/en-us/windows-server/storage/refs/integrity-streams
If you cannot see any validation files or a difference, since I suppose you have more than 1 folder containing the same file?
I would check the latest update on my server-pc-computer, I am thinking that if you did an installation from a different architecture type, then, it's possible that the controlling route now use an improved version and the initial function to start the app, or files have either move , or changed, or even be damaged...
If this app use a special package or limited files, and one files has been changed for X reason,
If the file is exactly the same, you could just change your diectory location to address the application when you call it.
Let me know if you find the issue!
Best regards!
- vadimnjDec 30, 2024Copper Contributor
And btw, If I change HKEY_CLASSES_ROOT\DesktopBackground\Shell\toy\command @="toy"
to full path HKEY_CLASSES_ROOT\DesktopBackground\Shell\toy\command @="C:\Windows\test\toy"
it works fine. Why? So the file is good. I am 100% sure. Just when it's starting from the registry command, the sys variable path is ignored. - vadimnjDec 30, 2024Copper Contributor
Actually, toy.exe is a simplest vb.net console application consisting of just two lines of code. For testing purposes only.
Sub Main() MsgBox("Test") End SubAnd one more thing, if I move it to the windows directory, it works fine from the command line and from the registry command. But if I move it back to windows\test, it only works from the command line. From the registry, just nothing. No errors, no msgbox, just nothing.
- ArmandJan 01, 2025Brass Contributor
Interesting, I don't want to tell you or say information that is not accurate or make you waste your time searching and testing materials etc. I can't figure this one out I believe and I wish I had more time to help you out, since it might not be that hard or probably a simple option or a wrapper... (I was trying to debug this with copilot to see if this can help you and here is what I found, but it seems like you already use the path to bypass your toy.exe, so)
It should work as follow:
- When you run toy from cmd it use <Path> env variable to locate toy.exe in <C:\Windows\test>
- When you do it from the registry it doesn't use the <Path> env variable in the same way, that's why when you specify the full path <C:\Windows\test\toy.exe> work, but simply using <toy> does not
Proposed solution:
To make sure <toy.exe> run as it should from the registry, you need to use the full path in the registry command as this bypass the need for <Path> env variable and ensure that the correct file is accessed:
<HKEY_CLASSES_ROOT\DesktopBackground\Shell\toy\command @="C:\Windows\test\toy.exe">
By using the full path in the registry command it should work even with where <toy.exe> is accessed regardless of diff in env variable or path.- ArmandJan 01, 2025Brass Contributor
I was thinking that if you were to use SSH to access a physical desktop from a virtual location you could have a sync problem, let me know if I can look furtner to help you out!
Have a great evening!