In an enterprise Windows 7 machine we cannot control the system environment variables including _JAVA_OPTIONS, JAVA_HOME and _classload_hook. These values are set to suit other java-using programs such as QTP. These alien settings cause the slave to fail to start with errors like: "Error: could not load Mercury Interactive support. Please run the setup again. If the problem persists please contact Mercury's Customer support. Picked up _JAVA_OPTIONS: -Xrunjvmhook -Xbootclasspath/a:C:\PROGRA~2\HP\QUICKT~1\bin\JAVA_S~1\classes;C:\PROGRA~2\HP\QUICKT~1\bin\JAVA_S~1\classes\jasmine.jar"
A cure is to manually delete the offending system environment variables in the registry.
Sadly these variables are set by group policy and are reset when the machine is restarted. (Restarting the machine is the only safe way to get services.exe to reload it's environment.)
So whenever the machine is restarted (and this can be randomly enforced centrally) the Jenkins slave fails.
It would be really super if the jenkins-slave.exe could isolate the JVM from the background environment. jenkins-slave.xml could be enhanced to provide key-value pairs for environment variables, and a way to undefine environment bindings. Or perhaps use existing java service wrappers.