OK, one workaround is to do the following.

1. Run the jenkins service as a "normal" user, edit this in "local services" in windows. Apparently things go wild if you use cygwin as the SYSTEM user. This is on the slave, of course.

2. Remove the #!/bin/bash shebang line from the first line of the script.

This works, although it is not very stable, the slave gets disconnected often, and the job gets killed. But this is probably another issue.

I cant get this plugin to find my cygwin install regardless of the user that the service is started as... I've tried everything. My registry entry is correct as described above (i.e. HKEY_LOCAL_MACHINE\Software\Cygwin\setup is c:\cygwin64)

I'm seeing this bug too. I ran the failing line using the jython console. I tried both

SOFTWARE\\Cygwin

and

SOFTWARE\\Wow6432Node\\Cygwin

and they both failed. It does, however, find plain ol' "SOFTWARE". Also, I try other keys such as

SOFTWARE\\[Motorola,Intel,TrendMicro]

and it finds all of them. So this seems to be a cygwin-specific problem.

>>> RegistryKey.LOCAL_MACHINE.openReadonly("SOFTWARE\\Cygwin")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
        at hudson.util.jna.RegistryKey.check(RegistryKey.java:124)
        at hudson.util.jna.RegistryKey.open(RegistryKey.java:223)
        at hudson.util.jna.RegistryKey.openReadonly(RegistryKey.java:218)
        at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)

hudson.util.jna.JnaException: hudson.util.jna.JnaException: Win32 error: 2 - The
 system cannot find the file specified

I'm also having this problem (at least from the description, it looks similar).

I tracked it down to difference between 32bit JVM vs 64bit JVM.
The plugin was consistently failing with 32bit JVM (Java 7) and it works with 64bit JVM.
My environment:
64-bit Windows 7 (6.1.7601 Service Pack 1 Build 7601)
64-bit JVM:

  java version "1.7.0_40"
  Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
  Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)

32-bit JVM:

  java version "1.7.0_40"
  Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
  Java HotSpot(TM) Client VM (build 24.0-b56, mixed mode, sharing)

If I open registry editor, then I can see that "HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup" key exists.
Other options that cygpath plugin tried to locate do not exist. All options:

1. HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Cygwin\setup
2. HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Cygnus Solutions\Cygwin\mounts v2\/
3. HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup
4. HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
   (so, the third should succeed)

The problem is the "access" flag that is passed to "RegOpenKeyEx" API call: it has the value for READ_ONLY (0x20019) but should also contain either 0x0100 (KEY_WOW64_64KEY) or 0x0200 (KEY_WOW64_32KEY), depending on the running JVM (either 32bits or 64bits).

The relevant part in RegistryKey class:
https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/util/jna/RegistryKey.java#L217

Useful reading:
http://windowsitpro.com/systems-management/whats-wow6432node-under-hkeylocalmachinesoftware-registry-subkey
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384129(v=vs.85).aspx

Also, I'm not sure the change made in JENKINS-7303 actually fixes anything (did someone test this?). The "Wow6432Node" subkey seems to be implementation detail of Windows registry and the application code should not care about it. Instead, it should use the relevant access bit (as described above). Also, my tests have shown that with current code, 64bit JVM running on 64bit Windows can access "HKEY..WARE\Cygwin\setup".

The problem is with 32bit JVM running on 64bit Windows: it looks up "HKEY..WARE\Cygwin\setup" but Windows translates that into "HKEY..WARE\Wow6432Node\Cygwin\setup" (which is missing). And, when it tries to access "HKEY..WARE\Wow6432Node\Cygwin\setup", Windows probably translates that into "HKEY..WARE\Wow6432Node\Wow6432Node\Cygwin\setup" which is also missing. So 32bit JVM running on 64bit Windows has no access to "HKEY..WARE\Cygwin\setup" unless it specifies the special KEY_WOW64_64KEY flag.

I'm not sure if the other scenario of 64bit JVM running on 64bit Windows trying to look up "HKEY..WARE\Wow6432Node\Cygwin\setup" works or KEY_WOW64_32KEY flag should be used instead (covering the case when "HKEY..WARE\Cygwin\setup" is missing but "HKEY..WARE\Wow6432Node\Cygwin\setup" exists). Should probably test that.