Possibly a duplicate of JENKINS-4859?

Seems to be the same.
Here is the stack trace I get on Windows 7 64, which is the same trace than JENKINS-4859

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.winreg.smb.JIWinRegStub.winreg_CreateKey(JIWinRegStub.java:297)
at org.jinterop.dcom.core.JIComServer.initialise(JIComServer.java:480)
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: org.jinterop.dcom.common.JIRuntimeException: 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.winreg.IJIWinReg$createKey.read(IJIWinReg.java:459)
at ndr.NdrObject.decode(NdrObject.java:19)
at rpc.ConnectionOrientedEndpoint.call(ConnectionOrientedEndpoint.java:138)
at rpc.Stub.call(Stub.java:112)
at org.jinterop.winreg.smb.JIWinRegStub.winreg_CreateKey(JIWinRegStub.java:291)
... 10 more

A duplicate of JENKINS-6385 except for 64 bit machines perhaps? I posted a fix that seems to be working for me on that issue since my Windows 7 box is 32 bit.

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.