[GH-ISSUE #67] Access to PRemoteM.ini is Denied

kerem commented

2026-02-28 12:00:47 +03:00

Owner

Originally created by @valsamis-d on GitHub (Jan 27, 2021).
Original GitHub issue: https://github.com/1Remote/1Remote/issues/67

Originally assigned to: @VShawn on GitHub.

Description
I have enabled "Run automatically at OS startup" and "Start Minimize". Every time I restart my laptop it goes over the cycle of 1st execution and finally displays the following error message:

However, the app is 'installed' on drive [P] rather than [C]:

To Reproduce
Steps to reproduce the behavior:

Extract archive into a drive/directory other than [C]
Execute it for the 1st time
Restart PC
See the prompts of 1st time execution and eventually the error:

Expected behavior
After restarting I expect a 'silent' restart of PRemote>

Screenshots
See above

Desktop (please complete the following information):

OS: Windows 10 Enterprise (20H2)
PRemoteM Version: 0.5.8.2101192131

Additional context
None

Originally created by @valsamis-d on GitHub (Jan 27, 2021). Original GitHub issue: https://github.com/1Remote/1Remote/issues/67 Originally assigned to: @VShawn on GitHub. **Description** I have enabled "Run automatically at OS startup" and "Start Minimize". Every time I restart my laptop it goes over the cycle of 1st execution and finally displays the following error message: ![image](https://user-images.githubusercontent.com/17590539/105962418-77ffbe80-6088-11eb-834d-e14f763b34b5.png) However, the app is 'installed' on drive [P] rather than [C]: ![image](https://user-images.githubusercontent.com/17590539/105962528-a1204f00-6088-11eb-8bc2-ef20d1cde6a7.png) **To Reproduce** Steps to reproduce the behavior: 1. Extract archive into a drive/directory other than [C] 2. Execute it for the 1st time 3. Restart PC 4. See the prompts of 1st time execution and eventually the error: ![image](https://user-images.githubusercontent.com/17590539/105962418-77ffbe80-6088-11eb-834d-e14f763b34b5.png) **Expected behavior** After restarting I expect a 'silent' restart of PRemote> **Screenshots** See above **Desktop (please complete the following information):** - OS: Windows 10 Enterprise (20H2) - PRemoteM Version: 0.5.8.2101192131 **Additional context** None

kerem

2026-02-28 12:00:47 +03:00

closed this issue
added the
bug

general-supportive

priority-hi
labels

kerem commented

2026-02-28 12:00:48 +03:00

Author

Owner

@majkinetor commented on GitHub (Jan 27, 2021):

For now I believe you can quickly solve this with:

Disable automatic startup in app
Create a shortcut to your installation and set up working dir to your install dir
Open Shell:startup (via WIN+R) and move the shortcut there

@majkinetor commented on GitHub (Jan 27, 2021): For now I believe you can quickly solve this with: 0. Disable automatic startup in app 1. Create a shortcut to your installation and set up working dir to your install dir 2. Open Shell:startup (via WIN+R) and move the shortcut there

kerem commented

2026-02-28 12:00:48 +03:00

Author

Owner

@VShawn commented on GitHub (Jan 27, 2021):

bug confirm.

In fact You are not the first reportor of this bug. I thought I figured out the reason last week, but now it looks different from what I thought.

https://github.com/VShawn/PRemoteM/blob/dev/PRemoteM/App.xaml.cs#L161-L175

checking the code:

Line 174 should set iniOnCurrentPath = P:\PApps\PRmoteMPortable\PRmoteM.ini

But it seems like it redirects to C:\WINDOWS\system32\PRmoteM.ini

It's very strange

I will try to find out what happened.

BTW, can you help to test new fix release latter? I can't reproduce this bug on neither of my PCs（1 laptop, 2 desktops）

@VShawn commented on GitHub (Jan 27, 2021): bug confirm. In fact You are not the first reportor of this bug. I thought I figured out the reason last week, but now it looks different from what I thought. https://github.com/VShawn/PRemoteM/blob/dev/PRemoteM/App.xaml.cs#L161-L175 checking the code: Line 174 should set `iniOnCurrentPath` = `P:\PApps\PRmoteMPortable\PRmoteM.ini` But it seems like it redirects to `C:\WINDOWS\system32\PRmoteM.ini` It's very strange I will try to find out what happened. BTW, can you help to test new fix release latter? I can't reproduce this bug on neither of my PCs（1 laptop, 2 desktops）

kerem commented

2026-02-28 12:00:48 +03:00

Author

Owner

@majkinetor commented on GitHub (Jan 27, 2021):

I was bitten by this several times and it relates to working dir, it has nothing to do with drive. Thats the reason I added this line recently to chocolatey package.

Maybe PRM should handle this by trying to access several locations for ini file if all previous attempts fail, including its own directory.

Order could be:

User specific dir in roaming folder
Its own folder
Current working dir

It stops as soon as it finds its ini file.

Other, idea is to allow specification of working dir via command line:

prm -workDir c:\PRMData\DataDir1

This would allow using one installation with multiple configurations and databases and would allow easy solution to startup problem by adding this param to the registry.

@majkinetor commented on GitHub (Jan 27, 2021): I was bitten by this several times and it relates to working dir, it has nothing to do with drive. Thats the reason I added [this line](https://github.com/majkinetor/au-packages/blob/master/premotem/tools/chocolateyInstall.ps1#L32) recently to chocolatey package. Maybe PRM should handle this by trying to access several locations for ini file if all previous attempts fail, including its own directory. Order could be: 1. User specific dir in roaming folder 2. Its own folder 3. Current working dir It stops as soon as it finds its ini file. Other, idea is to allow specification of working dir via command line: ``` prm -workDir c:\PRMData\DataDir1 ``` This would allow using one installation with multiple configurations and databases and would allow easy solution to startup problem by adding this param to the registry.

kerem commented

2026-02-28 12:00:48 +03:00

Author

Owner

@VShawn commented on GitHub (Jan 27, 2021):

User specific dir in roaming folder

I dont think a specific path would be good. If we do that, PRM will not a real portable app anymore.
I hope it will read the ini file in the app path first, so that the user can be able to carry the app/ini file/database in a USB flash drive, and use it directly on any computer that has not installed PRM.

it relates to working dir

also it seems like not totally about working dir

I created a shortcut of PRM, set working dir to C:\WINDOWS\system32, double click to run.
Or I run from powershell base on C:\WINDOWS\system32

and nothing happen, PRM just works fine

find this
https://stackoverflow.com/questions/1321628/environment-currentdirectory-in-c-net

@VShawn commented on GitHub (Jan 27, 2021): > User specific dir in roaming folder I dont think a specific path would be good. If we do that, PRM will not a real portable app anymore. I hope it will read the ini file in the app path first, so that the user can be able to carry the app/ini file/database in a USB flash drive, and use it directly on any computer that has not installed PRM. > it relates to working dir also it seems like not totally about working dir - I created a shortcut of PRM, set working dir to `C:\WINDOWS\system32`, double click to run. - Or I run from powershell base on `C:\WINDOWS\system32` ![image](https://user-images.githubusercontent.com/10143738/105970654-92578d80-60c4-11eb-8b56-26a165c4085f.png) and nothing happen, PRM just works fine --- find this https://stackoverflow.com/questions/1321628/environment-currentdirectory-in-c-net

kerem commented

2026-02-28 12:00:48 +03:00

Author

Owner

@majkinetor commented on GitHub (Jan 27, 2021):

I dont think a specific path would be good. If we do that, PRM will not a real portable app anymore.

I meant specific user folder, the one that PRM already uses in AppData

I hope it will read the ini file in the app path first

This is OK in portable scenario, not OK in setup.exe scenario where user can't write in ProgramFiles but since we don't have that now (and possible ever) then its OK. You still need to prefer one location over another tho - AppData or PrmInstallDir ? I would go with AppData first if it exists, InstallDir next (allows 1 portable installation of PRM for multiple users). This could be changed via command line (i.e. -portable flag to not look into AppData)

@majkinetor commented on GitHub (Jan 27, 2021): > I dont think a specific path would be good. If we do that, PRM will not a real portable app anymore. I meant specific user folder, the one that PRM already uses in AppData > I hope it will read the ini file in the app path first This is OK in portable scenario, not OK in setup.exe scenario where user can't write in ProgramFiles but since we don't have that now (and possible ever) then its OK. You still need to prefer one location over another tho - AppData or PrmInstallDir ? I would go with AppData first if it exists, InstallDir next (allows 1 portable installation of PRM for multiple users). This could be changed via command line (i.e. `-portable` flag to not look into AppData)

kerem commented

2026-02-28 12:00:48 +03:00

Author

Owner

@valsamis-d commented on GitHub (Jan 27, 2021):

For now I believe you can quickly solve this with:

1. Disable automatic startup in app

2. Create a shortcut to your installation and set up working dir to your install dir

3. Open Shell:startup (via WIN+R) and move the shortcut there

This workaround worked just fine! Thanks :)

@valsamis-d commented on GitHub (Jan 27, 2021): > > > For now I believe you can quickly solve this with: > > 1. Disable automatic startup in app > > 2. Create a shortcut to your installation and set up working dir to your install dir > > 3. Open Shell:startup (via WIN+R) and move the shortcut there This workaround worked just fine! Thanks :)

kerem commented

2026-02-28 12:00:48 +03:00

Author

Owner

@valsamis-d commented on GitHub (Jan 27, 2021):

BTW, can you help to test new fix release latter? I can't reproduce this bug on neither of my PCs（1 laptop, 2 desktops）

Sure I will, as soon as the new release is posted. Thanks!

@valsamis-d commented on GitHub (Jan 27, 2021): > BTW, can you help to test new fix release latter? I can't reproduce this bug on neither of my PCs（1 laptop, 2 desktops） Sure I will, as soon as the new release is posted. Thanks!

kerem commented

2026-02-28 12:00:48 +03:00

Author

Owner

@majkinetor commented on GitHub (Jan 27, 2021):

@valsamis-d

You can do that quickly via choco: $Env:ChocolateyToolsLocation = 'D:\bla'; cinst premotem

@majkinetor commented on GitHub (Jan 27, 2021): @valsamis-d You can do that quickly via choco:` $Env:ChocolateyToolsLocation = 'D:\bla'; cinst premotem`

kerem commented

2026-02-28 12:00:48 +03:00

Author

Owner

@valsamis-d commented on GitHub (Jan 27, 2021):

@valsamis-d

You can do that quickly via choco: $Env:ChocolateyToolsLocation = 'D:\bla'; cinst premotem

@majkinetor, unfortunately, I'm far from having even the slightest idea what the above means :( I'm sorry :(

@valsamis-d commented on GitHub (Jan 27, 2021): > > > @valsamis-d > > You can do that quickly via choco:` $Env:ChocolateyToolsLocation = 'D:\bla'; cinst premotem` @majkinetor, unfortunately, I'm far from having even the slightest idea what the above means :( I'm sorry :(

kerem commented

2026-02-28 12:00:48 +03:00

Author

Owner

@VShawn commented on GitHub (Jan 28, 2021):

@valsamis-d
I fix this by set working dir in code:
https://github.com/VShawn/PRemoteM/blob/dev_fix/PRemoteM/App.xaml.cs#L219

Expecting you to help me test it if you are free

PRemoteM 0.5.8.2101282043.zip

@VShawn commented on GitHub (Jan 28, 2021): @valsamis-d I fix this by set working dir in code: https://github.com/VShawn/PRemoteM/blob/dev_fix/PRemoteM/App.xaml.cs#L219 Expecting you to help me test it if you are free [PRemoteM 0.5.8.2101282043.zip](https://github.com/VShawn/PRemoteM/files/5887254/PRemoteM.0.5.8.2101282043.zip)

kerem commented

2026-02-28 12:00:48 +03:00

Author

Owner

@valsamis-d commented on GitHub (Jan 28, 2021):

Expecting you to help me test it if you are free

PRemoteM 0.5.8.2101282043.zip

@VShawn tested this as following and worked just fine :)

Removed shortcut from "Shell:Startup"
Executed 'exe' from the 'PRemoteM.0.5.8.2101282043' version
Enabled option "Run automatically at OS startup"
Reboot

PMRemoteM started just fine, without any error and with respecting my existing 'PRemoteM.ini'

Thank you!

@valsamis-d commented on GitHub (Jan 28, 2021): > > Expecting you to help me test it if you are free > > [PRemoteM 0.5.8.2101282043.zip](https://github.com/VShawn/PRemoteM/files/5887254/PRemoteM.0.5.8.2101282043.zip) > @VShawn tested this as following and worked just fine :) 1. Removed shortcut from "Shell:Startup" 2. Executed 'exe' from the 'PRemoteM.0.5.8.2101282043' version 3. Enabled option "Run automatically at OS startup" 4. Reboot PMRemoteM started just fine, without any error and with respecting my existing 'PRemoteM.ini' Thank you!

kerem referenced this issue

2026-02-28 12:07:16 +03:00

[PR #1012] [CLOSED] Fix process access exception in integrated SSH/SFTP connections #1901

kerem referenced this issue

2026-03-01 17:23:33 +03:00

[PR #1012] [CLOSED] Fix process access exception in integrated SSH/SFTP connections #2864

kerem referenced this issue

2026-03-13 13:02:18 +03:00

[PR #1012] [CLOSED] Fix process access exception in integrated SSH/SFTP connections #3863

Rows
Columns

[GH-ISSUE #67] Access to PRemoteM.ini is Denied #1012