Made the try for the fix suggested in JENKINS-6385 (set user name to "user.machinename"), but without success:

ERROR: Access is denied. See http://wiki.jenkins-ci.org/display/JENKINS/Windows+slaves+fail+to+start+via+DCOM for more information about how to resolve this.
org.jinterop.dcom.common.JIException: Access is denied, please check whether the [domain-username-password] are correct. Also, if not already done please check the GETTING STARTED and FAQ sections in readme.htm. They provide information on how to correctly configure the Windows machine for DCOM access, so as to avoid such exceptions. [0x00000005]
at org.jinterop.dcom.core.JIComServer.init(JIComServer.java:542)
at org.jinterop.dcom.core.JIComServer.initialise(JIComServer.java:458)
at org.jinterop.dcom.core.JIComServer.<init>(JIComServer.java:427)
at org.jvnet.hudson.wmi.WMI.connect(WMI.java:41)
at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:137)
at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:183)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: rpc.FaultException: Received fault. (unknown)
at rpc.ConnectionOrientedEndpoint.call(ConnectionOrientedEndpoint.java:142)
at rpc.Stub.call(Stub.java:112)
at org.jinterop.dcom.core.JIComServer.init(JIComServer.java:538)
... 10 more

One point of note is that when I use "user.machinename" it still sometimes throws the error but then manages to connect after 10-15 seconds. Will take a closer look at the machine to see what else I could have changed to fix the issue.

I found a high-risk workaround from this j-interop forum post: http://sourceforge.net/projects/j-interop/forums/forum/840678/topic/3398900
It's high-risk because it requires you to modify a Windows Resource Protection registry key, so perform the following steps at your own risk with caution.

The workaround was provided by csturtz in the j-interop forum post:

I ran into this same issue on Windows 2008 R2. The application I have accesses process information from the remote host. It uses auto registration set to true. It was failing for me when JInterop tried to modify the registry because the items it needed to modify had an owner of Trusted Installer and nothing else could touch them (not even if you logged in as an administrator and tried modifying them yourself). I did find a work-around that worked for me. I've heard it doesn't work for everyone, but it might be worth a shot.
1. Login to the target remote host as an Administrator.
2. Run the program Regedit
3. If you are asked to allow the Regedit program to make changes to the computer, click 'Yes'
4. Navigate to the Registry item HKEY_CLASSES_ROOT\CLSID{YOUR CLSID HERE}
5. Right click on this item and select 'Permissions'
6. Click 'Advanced'
7. Select the 'Owner' tab
8. In the 'Change Owner to...' box, highlight the account you are currently logged in as.
9. Click 'Ok'
10. Click 'Ok'
11. Right click the registry item again and select 'Permissions'
12. Highlight the 'Administrators' group 13. Give 'Full Control' permissions to this group by checking the 'Allow' box
14. Click 'Ok'

The registry key that needs to be modified is found from this line of the stack trace at org.jvnet.hudson.wmi.WMI.connect(WMI.java:41) i.e. *

*

In my case, the Windows 7 slave machine wasn't on a domain so for the Administrator username I specified SLAVE_MACHINE_NAME\Administrator. After a restart of the slave machine, the master installed and started the Hudson slave service with a new service name 'Hudson Slave at C:\hudson' (it previously was named just 'Hudson Slave'). The master has been able to successfully start the stopped slave service multiple times now without error. I hope this helps anyone else who was pulling out their hair looking for a fix.

Great tip.
Works for me!

Another tip to add to this. This may be obvious to others, but it wasn't to me, so maybe this will help someone else who stumbles onto this.

I made the registry change mentioned above, and got past the 'access denied' exception. However, it still didn't work. Turns out, the slave machine tries to run javaw.exe. On Windows 7 64-bit, this is installed in C:\Windows\SysWOW64. However, that directory wasn't in my path. So the Hudson slave wouldn't launch, and the application logs would show 'could not find the specified file' error messages. After adding this directory to the PATH environment variable and restarting the PC, I was finally able to connect.

I tested this with Jenkins 1.397 SNAPSHOT and still has this problem.
According to Changelog for 1.387 "* Install as a service" now supports Vista and Windows 7." it should have been resolved, but apparently not for 64-bit.

My Java is in the C:\windows\system32\java.exe so I do not have the PATH issue.
I solved it manually the following way:
1. I copied the jenkins-slave.exe, jenkins-slave.xml and slave.jar to the workspace C:\hudson on the slave machine.
2. Edit the XML file to replace @ID@ @APP@ and @ARGS@ with the correct values for this slave.
3. Open a cmd window in administrator mode and run 'jenkins-slave.exe install'
4. Start administer services and choose properties for the 'Jenkins Slave' service.
5. Choose to add a logon to the service using a local user (same user the build master uses to log on with) with administer group membership.
6. start the service
7. configure the build on the build master to use windows service to connect to slave.

This works for me

I do not know if all these steps are necessary, but...

I would be nice if someone with knowledge on this on Windows 7 64bit could find a way to start a service remote from Hudson/Jenkins.

I found a way / workaround to launch a Windows 64 Bit slave from a windows master:

Use JNPL to launch a 64 bit windows slave.

On the jenkins master platform:

• Launch a jenkins instance
• jenkins- web UI:
• manage nodes - new node
• Configure a node to the slave machine to launch it as a JNPL slave agent
• save the configuration

On the jenkins slave platform:

• launch a jenkins instance
• jenkins- web UI:
• manage nodes - new node
• Configure a node on this machine (take the physical IP number of the slave platform) to launch it as a JNPL slave agent
• Remember the home directory of the slave (e.g. ....\.jenkins\slave)
• launch the slave agent
• in the slave agent window choose "File" > "Install as Windows Service" from the menu
• Confirm your intention to install as a service.
• Once the installation succeeds, you'll be asked if you'd like to stop the current slave agent and immediately start a slave agent.
• When you click "OK", the slave agent window will terminate.
• stop the jenkins instance now.

• Open the windows services using services.msc in the command shell
• the "Jenkins Slave" now will be listed as a service
• open it to check it's general properties to start the service automatically

• In file browser browse to the directory of the slave (e.g. ....\.jenkins\slave)
• edit the file jenkins-slave.xml
• search for "localmachine" and replace it to the physical IP- number of the jenkins master platform
• save the jenkins-slave.xml
• restart the "Jenkins Slave" service

• now the slave platform will automatically start the jenkins slave connected via JNPL agent to the master platform

If you have the Remote Registry service running, try connecting to the registry on your slave via regedit on another machine. If you get a similar error ("Access is denied"), run powershell as an administrator on the slave, and execute Enable-PSRemoting.

This should allow remote access to the registry; you may still require fixing permissions on the registry key as mentioned elsewhere.

There's a workaround less complicated thanks to Florian Vogler from Hudson-ci wiki.
It can be applied to Microsoft Windows 7 too.

"This is caused by the TrustedInstaller concept of windows.

Solution I found so far:

Hudson requires full access to WBEM Scripting Locator (HKEY_CLASSES_ROOT\CLSID

'
Right click and select 'Permissions'
Change owner to administrators group.
Change permissions for administrators group. Grant Full Control.
Change owner back to TrustedInstaller (user is "NT Service\TrustedInstaller")
Restart Remote Registry Service"

It looks like there's no recent issues with this type of slave launch that isn't covered by the wiki page (the WBEM one was mentioned at least twice in the comments here already), therefore I'm resolving as Incomplete.

If you encounter a similar issue on a recent Jenkins version and tried everything on the linked wiki page with no success, please file a new issue and add a link back to this one.