Do you have tested the nvInject plugin?
Maybe it is an alternative to your issue.
Anyway, you could use the EnvInject plugin to setup the job workspace.

Here is the full stacktrace from the console when the pre-scm build plugin tries to reference the non-existent workspace. This will happen any time a new job which has no namespace in the slave filesystem uses the pre-scm plugin.

Started by user <username>
Building remotely on <slave node> in workspace /some/path/on/slave
Running Prebuild steps
[<job name>] $ cmd /c call C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\hudson334444854237146312.bat
The directory name is invalid
FATAL: command execution failed
java.io.IOException: Cannot run program "cmd" (in directory "/some/path/on/slave"): CreateProcess error=267, The directory name is invalid
at java.lang.ProcessBuilder.start(Unknown Source)
at hudson.Proc$LocalProc.<init>(Proc.java:244)
at hudson.Proc$LocalProc.<init>(Proc.java:216)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:707)
at hudson.Launcher$ProcStarter.start(Launcher.java:338)
at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:932)
at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:899)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at hudson.remoting.Engine$1$1.run(Engine.java:60)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: CreateProcess error=267, The directory name is invalid
at java.lang.ProcessImpl.create(Native Method)
at java.lang.ProcessImpl.<init>(Unknown Source)
at java.lang.ProcessImpl.start(Unknown Source)
... 17 more
Failed build for hudson.tasks.BatchFile@535c37ae

Updated the issue.
I suppose it is not related to [pre-scm-buildstep], because it also appears in other build steps

Oleg: I don't see the core issue here. Could you elaborate? Automatic creation of the directory could well hide bugs.

The issue rarely appears in following plugins:

• Wokspace cleanup plugin
• Perforce plugin

BTW, I'm also not sure about the issue's origin.
It could be caused by JNA libraries, FileSystem / OS specifics, etc., etc.
All plugins use Jenkins core's methods to manage directories, I've supposed that it's better to re-assign the issue to the core

Somehow I do always get this bug while trying to start Windows slaves from a Linux jenkins instance via SSH. SSH is configured properly on the machine and jenkins is configured to start a session using the Administrator account, which works fine.

The log is available at https://gist.github.com/ssbarnea/370949586b622f751d07 and the important part being:

#./deploy/slave-setup.sh
' on tocco
[marvin] $ /bin/bash C:\Users\Administrator\hudson5000371039477233927.sh
hudson.util.IOException2: Slave JVM has not reported exit code. Is it still running?
	at hudson.plugins.sshslaves.SSHLauncher.startSlave(SSHLauncher.java:953)
	at hudson.plugins.sshslaves.SSHLauncher.access$400(SSHLauncher.java:133)
Caused by: java.io.IOException: Cannot run program "/bin/bash" (in directory "C:\tools\cygwin\home\Administrator\marvin\marvin"): CreateProcess error=3, The system cannot find the path specified
	at java.lang.ProcessBuilder.start(Unknown Source)
	at hudson.Proc$LocalProc.<init>(Proc.java:244)

The windows path is correct, being created by Jenkins, but it seems that he execution of /bin/bash is the one that fails. If one does manually performs ssh to the machine, using the same credentials, they would be able to run /bin/bash.

I believe that the problem is because Jenkins is assuming that being a Windows machine it has to provide a Windows path to the CreateProcess which probably expects a Unix path instead because the entire shell is run under cygwin.

Still, I tried any combinations of configuring the slave path on the node configuration but none seems to work.