NSIS installer causes APPDATA variable to disappear from environment

forest_gump · 4th October 2011, 05:15

I'm facing a very unusual problem that occurs on a few PCs only, and don't have a clue on where to begin. I have an NSIS based installer which uses the following plugins and runs in admin mode.

!include MUI2.nsh
!include LogicLib.nsh
!include Library.nsh
!include EnvVarUpdate.nsh
!include "winmessages.nsh"

On some PCs, the windows APPDATA environment variable "goes away" from explorer.exe's environment space when my installer has completed running i.e. we cannot echo it anymore on a new cmd shell started after the installer is complete. The only way to get it back is to kill explorer.exe and restart it or reboot the PC. Note, my installer does not use APPDATA directly at all.
This is reproducible every time on certain PCs. so far I've observed this on XP PCs only. We think some shell extension is corrupting environment space but can't figure out which one. Clearly NSIS or one of it's extensions seems to be playing a role in corrupting the environment space. What could be going on behind the scenes that could cause such a behavior ? Can anyone please help ?

forest_gump · 4th October 2011, 05:16

Oh, I forgot to say that I'm using NSIS 2.46 (large).

forest_gump · 5th October 2011, 23:22

can anyone please help give a clue ? is this a known issue ?

Afrow UK · 6th October 2011, 11:07

If it's a known issue then you will find it by searching. Otherwise, it must be something in your script.

Stu

MSG · 6th October 2011, 19:50

Well it's not that it MUST be something in the script, but it probably is. Please supply us with a minimal script that reproducibly shows this problem.

Anders · 7th October 2011, 07:19

I'm guessing !include EnvVarUpdate.nsh and its code is the problem, generally the env. scripts on the wiki are unsafe

4th October 2011, 05:15	#1
forest_gump Junior Member Join Date: Oct 2011 Posts: 3	NSIS installer causes APPDATA variable to disappear from environment I'm facing a very unusual problem that occurs on a few PCs only, and don't have a clue on where to begin. I have an NSIS based installer which uses the following plugins and runs in admin mode. !include MUI2.nsh !include LogicLib.nsh !include Library.nsh !include EnvVarUpdate.nsh !include "winmessages.nsh" On some PCs, the windows APPDATA environment variable "goes away" from explorer.exe's environment space when my installer has completed running i.e. we cannot echo it anymore on a new cmd shell started after the installer is complete. The only way to get it back is to kill explorer.exe and restart it or reboot the PC. Note, my installer does not use APPDATA directly at all. This is reproducible every time on certain PCs. so far I've observed this on XP PCs only. We think some shell extension is corrupting environment space but can't figure out which one. Clearly NSIS or one of it's extensions seems to be playing a role in corrupting the environment space. What could be going on behind the scenes that could cause such a behavior ? Can anyone please help ?

7th October 2011, 07:19	#6
Anders Moderator Join Date: Jun 2002 Location: ${NSISDIR} Posts: 5,449	I'm guessing !include EnvVarUpdate.nsh and its code is the problem, generally the env. scripts on the wiki are unsafe IntOp $PostCount $PostCount + 1

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

4th October 2011, 05:16	#2
forest_gump Junior Member Join Date: Oct 2011 Posts: 3	Oh, I forgot to say that I'm using NSIS 2.46 (large).

5th October 2011, 23:22	#3
forest_gump Junior Member Join Date: Oct 2011 Posts: 3	can anyone please help give a clue ? is this a known issue ?

6th October 2011, 11:07	#4
Afrow UK Moderator Join Date: Nov 2002 Location: Surrey, England Posts: 8,434	If it's a known issue then you will find it by searching. Otherwise, it must be something in your script. Stu

6th October 2011, 19:50	#5
MSG Major Dude Join Date: Oct 2006 Posts: 1,892	Well it's not that it MUST be something in the script, but it probably is. Please supply us with a minimal script that reproducibly shows this problem.