Startup settings disapear on closing "Startup and Tray Icon" window.

HyperSnap takes the path to user Startup folder from the Registry, under the following path:
 
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
 
The value it reads there is "Startup" REG_SZ value. What is this value on your users' computers? I don't know how I could programmatically find out a redirected user folder. If you have this information, please share and I may be able to implement such change in the next release of HyperSnap 8.
 
Greg

I did a test, by changing the registry key to 'C:\users\public\', and restarted HyperSnap. But HyperSnap still doesn't write any file there, nor does the tick in the checkbox stay.  
 
 Jan

I will do another test, trying to leave out our customizations.  
 
Looking at my procmon traces, it seems like there is a problem creating some files (My picture folder, and Startup folder). 
I will try to reduce the data, and may be able to provide the trace or some screenshots by PM. I don't want to publish some of the data on the internet. 
 
 
 

Hello Greg, 


I have gone through extensive testing. I used a vanilla Windows 10 device and experienced the same issue, if the device is joined to our domain and recieving our Group-Policies. I reviewed all policies, but couldn't identify the reason for the hypersnap startup lnk file not being created.
 
 
What I was able to reproduce though is, that it does work for local user accounts (which don't receive GPO, because the accounts don't belong to our domain). But this is no option. 
 
I changed our Folder-Redirection settings back to Microsoft default. That didn't help fixing the issue. 
 
I used powershell to simulate the creation of a symlink in the shell:startup folder. Which gives me a "Administrator privilege required for this operation.". Since I can't make our users local administrators, nor make them automatically run everything in administrative context, this doesn't help. 
 
I also checked a security Setting (secpol.msc) called 'Create symbolic links'. Microsoft implemented this to protect the system from hackers creating startup folder items. By default, creation of symbolic links is only allowed for local administrators. But even if I allow it to all 'users', it doesn't work in HyperSnap.
 
Finally, i wondered why other applications can start up with windows. I used a portable application called FreeDownloadManager (FDM) for testing. Within the application, I selected to start up with windows. What it does is: It creates a registry entry in: 
Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
 
So this application doesn't make use of the Shell:Startup folder, but it uses the RUN-Key in the registry. 
 
I tested with a manual run-Key entry: 
reg_sz "Hypersnap8"
value: "C:\Program Files\HyperSnap 8\HprSnap8.exe"
And Hypersnap was successfully loaded after logon. 
 
I would like to ask, if you may think about changing the HyperSnap startup mechanics to use the registry RUN key, instead of the shell:startup folder. Would that be feasible? 

Hello Greg, 
 
yes, this is a high priority topic for us, since the users can't configure Hypersnap to start up automatically on Windows 10. (We still can't find the reason for this). 
 
We are currently migrating our users to Windows 10. 
If you look at the Windows 10 task-manager ("more details" mode), there is a 'Startup' tab. If HyperSnap is added to the Registry's run-key, it will be listed there, and the user can disable the startup from there. No need to use 'regedit.exe' or go and find the 'Shell:Startup' folder which is not listed in the Windows 10 Start menu, anymore.
 
Nevertheless, If Hypersnap would give any error message or return code and path details, why the *.lnk file has not been created, I would be willing to do more research on this. But in the current situation I have tested everything that came to my mind. 
 
So personally, I would currently prefer the run-key variant.

I now released version 8.16.09 of HyperSnap, where the "auto-start with Windows" option is handled via the registry entries under
 
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
or
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
 
instead of the old Windows StartUp directory. Hope this helps, thanks!
 
Greg

Hello Greg, 
 
the new windows startup integration works very well. We are now preparing a deployment package for our company, and pilot the new version in a larger user group. 
 
Thank you very much for your support and effort you put into this!
 
Best regards,
Jan