Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-57477

Cancelling a job results in "sendctrlc.x64...exe" stops working

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • core
    • Jenkins Server: Jenkins ver. 2.148
      Slave is connected to a Windows Server 2012
    • Jenkins 2.178

      We have Jenkins that has several clients connected via the jenkins slave. We also do have a lot of different jobs.

      Now whenever one of these jobs is cancelled and the connected slave runs on a windows machine a dialog comes up stating that "sendctrlc.x64.E4257D768B94C95C4C6D7C260D4F9E8F.exe" has stopped working.

      These are the problem details:

      Problem signature:
      Problem Event Name: APPCRASH
      Application Name: sendctrlc.x64.E4257D768B94C95C4C6D7C260D4F9E8F.exe
      Application Version: 0.0.0.0
      Application Timestamp: 5b4ed6f8
      Fault Module Name: MSVCR120.dll
      Fault Module Version: 6.2.9200.22376
      Fault Module Timestamp: 5a90c271
      Exception Code: c0000135
      Exception Offset: 00000000000d22d0
      OS Version: 6.2.9200.2.0.0.400.8
      Locale ID: 1033
      Additional Information 1: ac05
      Additional Information 2: ac0507478d1c5bd693cfc4fe3987e900
      Additional Information 3: ac05
      Additional Information 4: ac0507478d1c5bd693cfc4fe3987e900

      Read our privacy statement online:
      http://go.microsoft.com/fwlink/?linkid=190175

      If the online privacy statement is not available, please read our privacy statement offline:
      C:\Windows\system32\en-US\erofflps.txt

          [JENKINS-57477] Cancelling a job results in "sendctrlc.x64...exe" stops working

          S R added a comment -

          I just upgraded the jenkins to the latest version. The error remains, but I see this stacktrace in the console now:

           

           

          java.lang.UnsatisfiedLinkError: Native Library C:\Users\brms\.jenkins\cache\jars\12\winp.x64.BD89A6734D0147A7868D1B98DB8EF12D.dll already lo
          aded in another classloader
                  at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1903)
                  at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1822)
                  at java.lang.Runtime.load0(Runtime.java:809)
                  at java.lang.System.load(System.java:1086)
                  at org.jvnet.winp.Native.loadDll(Native.java:243)
                  at org.jvnet.winp.Native.loadByUrl(Native.java:163)
                  at org.jvnet.winp.Native.load(Native.java:125)
                  at org.jvnet.winp.Native.<clinit>(Native.java:94)
                  at org.jvnet.winp.WinProcess.enableDebugPrivilege(WinProcess.java:245)
                  at hudson.util.ProcessTree$Windows.<clinit>(ProcessTree.java:671)
                  at hudson.util.ProcessTree.get(ProcessTree.java:426)
                  at hudson.Proc$LocalProc.destroy(Proc.java:384)
                  at hudson.Proc$LocalProc.join(Proc.java:357)
                  at hudson.Launcher$RemoteLaunchCallable$1.join(Launcher.java:1318)
                  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
                  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
                  at java.lang.reflect.Method.invoke(Method.java:497)
                  at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:929)
                  at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:903)
                  at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:855)
                  at hudson.remoting.UserRequest.perform(UserRequest.java:212)
                  at hudson.remoting.UserRequest.perform(UserRequest.java:54)
                  at hudson.remoting.Request$2.run(Request.java:369)
                  at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
                  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
                  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
                  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
                  at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:93)
                  at hudson.remoting.Engine$1$$Lambda$3/666634392.run(Unknown Source)
                  at java.lang.Thread.run(Thread.java:745)
          

           

          S R added a comment - I just upgraded the jenkins to the latest version. The error remains, but I see this stacktrace in the console now:     java.lang.UnsatisfiedLinkError: Native Library C:\Users\brms\.jenkins\cache\jars\12\winp.x64.BD89A6734D0147A7868D1B98DB8EF12D.dll already lo aded in another classloader         at java.lang. ClassLoader .loadLibrary0( ClassLoader .java:1903)         at java.lang. ClassLoader .loadLibrary( ClassLoader .java:1822)         at java.lang. Runtime .load0( Runtime .java:809)         at java.lang. System .load( System .java:1086)         at org.jvnet.winp.Native.loadDll(Native.java:243)         at org.jvnet.winp.Native.loadByUrl(Native.java:163)         at org.jvnet.winp.Native.load(Native.java:125)         at org.jvnet.winp.Native.<clinit>(Native.java:94)         at org.jvnet.winp.WinProcess.enableDebugPrivilege(WinProcess.java:245)         at hudson.util.ProcessTree$Windows.<clinit>(ProcessTree.java:671)         at hudson.util.ProcessTree.get(ProcessTree.java:426)         at hudson.Proc$LocalProc.destroy(Proc.java:384)         at hudson.Proc$LocalProc.join(Proc.java:357)         at hudson.Launcher$RemoteLaunchCallable$1.join(Launcher.java:1318)         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)         at java.lang.reflect.Method.invoke(Method.java:497)         at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:929)         at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:903)         at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:855)         at hudson.remoting.UserRequest.perform(UserRequest.java:212)         at hudson.remoting.UserRequest.perform(UserRequest.java:54)         at hudson.remoting.Request$2.run(Request.java:369)         at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)         at java.util.concurrent.FutureTask.run(FutureTask.java:266)         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)         at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:93)         at hudson.remoting.Engine$1$$Lambda$3/666634392.run(Unknown Source)         at java.lang. Thread .run( Thread .java:745)  

          I am having the same issue, however I seem to also get the error for successful builds. I have pipeline jobs that call a gradle wrapper with though 'bat' calls.

          It also seems as if the gradle daemon is not properly release because of this.

          Matthias Flock added a comment - I am having the same issue, however I seem to also get the error for successful builds. I have pipeline jobs that call a gradle wrapper with though 'bat' calls. It also seems as if the gradle daemon is not properly release because of this.

          Upvote Matthias.  Same.  

          AWs AMI windows serever 2012

          jenkins 2.150.1

          jdk: jdk-8u101-windows-x64.exe

           

          My QA engineers think one I gave them to test is working:

          AWS windows server2016

          jenkins 2.150.1
          jdk jdk-8u181-windows-x64.exe

           

          I will try JDK 8.181 on other systems tomorrow.

          Otherwise server 2016 is it.

          Issues is opsworks does not handle  server 2016 so I'll need to write a bootstrap script to run chef solo.

          michael pechner added a comment - Upvote Matthias.  Same.   AWs AMI windows serever 2012 jenkins 2.150.1 jdk: jdk-8u101-windows-x64.exe   My QA engineers think one I gave them to test is working: AWS windows server2016 jenkins 2.150.1 jdk jdk-8u181-windows-x64.exe   I will try JDK 8.181 on other systems tomorrow. Otherwise server 2016 is it. Issues is opsworks does not handle  server 2016 so I'll need to write a bootstrap script to run chef solo.

          Gwyn Judd added a comment -

          Try installing the VC++ runtime. Just a thought

          https://www.microsoft.com/en-nz/download/details.aspx?id=40784

          Gwyn Judd added a comment - Try installing the VC++ runtime. Just a thought https://www.microsoft.com/en-nz/download/details.aspx?id=40784

          Evgeniy added a comment -

          Hit the same issue on Windows 2012 R2:

          Installed Vcredist 2013 and it's working fine now.

          Evgeniy added a comment - Hit the same issue on Windows 2012 R2: Installed Vcredist 2013 and it's working fine now.

          I can confirm, with Vcredist installed the error no longer appears.

          Matthias Flock added a comment - I can confirm, with Vcredist installed the error no longer appears.

          Yoav Miles added a comment -

          mflock which version of vcredist please? I have 2008 & 2017 installed and they don't seem to remedy the crashes.

          Yoav Miles added a comment - mflock  which version of vcredist please? I have 2008 & 2017 installed and they don't seem to remedy the crashes.

          Evgeniy added a comment -

          towel, 2013.

           

          Evgeniy added a comment - towel , 2013.  

          Yoav Miles added a comment -

          Thanks!

          Yoav Miles added a comment - Thanks!

          It seems like we missed this ticket but this project is about the infrastructure running Jenkins. so I am moving this ticket on the JENKINS project in order to get more visibility from other contributors

          Olivier Vernin added a comment - It seems like we missed this ticket but this project is about the infrastructure running Jenkins. so I am moving this ticket on the JENKINS project in order to get more visibility from other contributors

          Oleg Nenashev added a comment -

          I missed this ticket due to the long break in the community, just noticed the ticket after it was moved.

          Generally we need a new winp version with https://github.com/kohsuke/winp/issues/58 . I will see what I can do about it.

          Oleg Nenashev added a comment - I missed this ticket due to the long break in the community, just noticed the ticket after it was moved. Generally we need a new winp version with  https://github.com/kohsuke/winp/issues/58  . I will see what I can do about it.

          Oleg Nenashev added a comment -

          Oleg Nenashev added a comment - https://github.com/jenkinsci/jenkins/pull/4029

          Oleg Nenashev added a comment -

          Released in Jenkins 2.178, will consider for LTS backporting

          Oleg Nenashev added a comment - Released in Jenkins 2.178, will consider for LTS backporting

          Please consider for back porting.  We only use LTS.

          michael pechner added a comment - Please consider for back porting.  We only use LTS.

          We also run LTS here, but installing Microsoft Visual C++ 2013 Redistributable (x64) - 12.0.40649 solved the crashes easily. I suggest not hurrying with the backport, in case there is some unexpected problem with the new winp version.

          Kalle Niemitalo added a comment - We also run LTS here, but installing Microsoft Visual C++ 2013 Redistributable (x64) - 12.0.40649 solved the crashes easily. I suggest not hurrying with the backport, in case there is some unexpected problem with the new winp version.

          Postponing this to 1.176.2 as the fix is quite new and there appear to be an alternative fix.

          Oliver Gondža added a comment - Postponing this to 1.176.2 as the fix is quite new and there appear to be an alternative fix.

            oleg_nenashev Oleg Nenashev
            sveri S R
            Votes:
            5 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated:
              Resolved: