I have a project that has been working in Windows 7 for some time now. When I execute the installer on Windows 10, the installer can't read a mapped drive, and I get many file and directory permission issues.
I am using the NSIS install system 3.02.1
I have tried the simple "RequestExecutionLevel admin" without any impact.
I have tried a more elaborate "packhdr" and "manifest" method without any success.
Anyone have any ideas on where and how to start debugging and fixing these issues?
Problems moving to Windows 10
8 posts
Here is where the first error occurs in Win10:
//${LogText} "Check the mapped drive T:"
//${IfNot} ${FileExists} "T:\config\prod_cfg\*.*"
// ${LogText} "The Application menu files do not exist."
// MessageBox MB_ICONINFORMATION|MB_OK "$(miscMessage0006)"
// Call ErrorHandler
//${EndIf}
Then the error handler tries to clean up temporary files and folders and I get a bunch more messages about copy and delete errors.
//${LogText} "Check the mapped drive T:"
//${IfNot} ${FileExists} "T:\config\prod_cfg\*.*"
// ${LogText} "The Application menu files do not exist."
// MessageBox MB_ICONINFORMATION|MB_OK "$(miscMessage0006)"
// Call ErrorHandler
//${EndIf}
Then the error handler tries to clean up temporary files and folders and I get a bunch more messages about copy and delete errors.
Did you map the drive before elevating to admin? Because a mapped drive is only available in the same context.
All drives are mapped long before NSIS is used. Drive mapping is done once then essentially never changed. All Windows 10 processes and Cygwin processes can see and use the mapped resources without any issues, same as Windows 7. It is only when using the installer on a Windows 10 system that the failures start to occur. I really never expected to see any issues so I am baffled that the errors even occur.
Compare running "net use" on the user's command prompt vs. an administrator command prompt (the same credentials you're using to run your installer) and you'll likely see the mapped drive in one but not the other (or the status might be Unavailable). The contexts are not completely independent, though, because the authentication to the mapped server will use the same credentials as the original map.
Personally, I would just avoid using mapped drives. I could see where there might be a convenience where you're using the same installer in different departments that use different servers but you're looking for files in an equivalent location on all of the servers, but even then you're asking for trouble because mapped drives regularly go awry.
Personally, I would just avoid using mapped drives. I could see where there might be a convenience where you're using the same installer in different departments that use different servers but you're looking for files in an equivalent location on all of the servers, but even then you're asking for trouble because mapped drives regularly go awry.
This has been covered many times before, both here on the forum and other places.
See also:
* https://blogs.msdn.microsoft.com/cja...windows-vista/
* https://support.microsoft.com/en-ie/...when-uac-is-co
See also:
* https://blogs.msdn.microsoft.com/cja...windows-vista/
* https://support.microsoft.com/en-ie/...when-uac-is-co
So do the UAC permission issues apply even when UAC is OFF (or at it's lowest setting, I assume this is off)? In the mean time I will try both suggestions; mapping in admin level, not using mapped drives.
When UAC is off there is no split token and no integrity levels so it should work for administrators. The lowest setting is probably not off, depends on your version. In Vista it was off but in 8 and 10 I think it is still on and you have to edit the registry to turn it off IIRC.
Using RunAs.exe as a normal user might not work because it is a different login session.
Using RunAs.exe as a normal user might not work because it is a different login session.