FULL PRODUCT VERSION :
java version "1.8.0_65"
Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows 7 Ultimate 64bit
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
We randomly receive the following NPE when launching an installed webstart application from a shortcut:

java.lang.NullPointerException
	at com.sun.javaws.JnlpxArgs.execProgram(Unknown Source)
	at com.sun.javaws.Launcher.relaunch(Unknown Source)
	at com.sun.javaws.Launcher.prepareResources(Unknown Source)
	at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
	at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
	at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
	at com.sun.javaws.Launcher.launch(Unknown Source)
	at com.sun.javaws.Main.launchApp(Unknown Source)
	at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
	at com.sun.javaws.Main.access$000(Unknown Source)
	at com.sun.javaws.Main$1.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

Cannot use secure launcher with main class: B 
#### Java Web Start Error:
#### null


Once we receive this exception, further attempts to re-launch continue to fail. 

The ways to recover we have found so far are:
1) Re-download the jnlp from the website, but this seems to only work for that run
2) Remove the application from the Java control panel and re-download jnlp
3) Toggling certain options in the control panel like 'Enable logging' 'Enable trace' cause it to work a few times, then fails.

When it fails, the error message always complains about a class that does not exist, for example 'B'. 
Sometimes it tries to use a random snippet of the java args in our jnlp file as the classname.

I wanted to attach a debugger to see where the corruption was taking place, but first tried launching the failing app from the cmd line.
Once I was able to consistently get the NPE, I opened up a cmd window and pasted the shortcut target and ran... and it ran fine. 
Double clicking the shortcut continued to fail.

Upon further investigation of what javaws.Main/Launcher is doing, appears the args that are passed are corrupt, at least the value of -Djnlpx.vmargs. 
This is a base64 string of the args used in the jnlp file, but sometimes the values when decoded result in garbage chars. 
The code that parses the classname out of the cmd string returns early because of these and results in the NPE.

An example good run has the following args:
jnlpx.offline=false
jnlpx.session.data=C:\Users\swerner\AppData\Local\Temp\session5619194532841944306
jnlpx.vmargs=LVhYOk5ld1NpemU9MTI4bQAtWFg6UGVybVNpemU9MTI4bQAtRGphdmEubmV0LnByZWZlcklQdjRTdGFjaz10cnVlAC1Ec3VuLmphdmEyZC5ub2RkcmF3PXRydWUALVhteDFnAC1YWDorVXNlQ29uY01hcmtTd2VlcEdDAC1YWDorQ01TUGVybUdlblN3ZWVwaW5nRW5hYmxlZAAtWFg6K0NNU0NsYXNzVW5sb2FkaW5nRW5hYmxlZAAtRHN1bi5qYXZhMmQuZDNkPWZhbHNlAC1EaW50ZWdyYXRhLmxvZ2luLm1vZGU9UHJvZHVjdGlvbgAtRGpib3NzLmRpc2NvdmVyeWhvc3RuYW1lPXBvcnRhbC5lbmZ1c2lvbnN5c3RlbXMuY29tAC1EamJvc3MuZGlzY292ZXJ5cG9ydD04NDQzAC1EY29tLnN1bi54bWwuYmluZC52Mi5ieXRlY29kZS5DbGFzc1RhaWxvci5ub09wdGltaXplPXRydWUALWVhOmNvbS5lbmZ1c2lvbi4uLgA=
sun.java.command=com.sun.javaws.Main -secure -notWebJava C:\Users\swerner\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\1\143a1481-774eee27

And a bad run:
jnlpx.vmargs=LURqYXZhLm5ldC5wcmVmZXJJUHY0U3RhY2s9dHJ1ZQAtRHN1bi5qYXZhMmQubm9kZHJhdz10cnVlAC1YWDpOZXdTaXplPTEyOG0ALVhYOlBlcm1TaXplPTEyOG0ALVhteDFnbHIAMADAMQAAQmUAAGh0dHBzX19fcG9ydGFsLmVuZnVzaW9uc3lzdGVtcy5jb21fbGF1bmNoZXJfaHR0cHNfX19wb3J0YWwuZW5mdXNpb25zeXN0ZW1zLmNvbV9sYXVuY2gtRGpubHAuYXBwbGljYXRpb24uaHJlZj1odHRwczovL3BvcnRhbC5lbmZ1c2lvbnN5c3RlbXMuY29tL2xhdW5jaGVyL2xhdW5jaGVyLmpubHAA
sun.java.command=com.sun.javaws.Main -notWebJava C:\Users\swerner\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\1\143a1481-774eee27

(I removed args that appeared in both or really have nothing to do with this issue)

In a good run the args are decoded as:
-XX:NewSize=128m
-XX:PermSize=128m
-Djava.net.preferIPv4Stack=true
-Dsun.java2d.noddraw=true
-Xmx1g
-XX:+UseConcMarkSweepGC
-XX:+CMSPermGenSweepingEnabled
-XX:+CMSClassUnloadingEnabled
-Dsun.java2d.d3d=false
-Dintegrata.login.mode=Production
-Djboss.discoveryhostname=portal.enfusionsystems.com
-Djboss.discoveryport=8443
-Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true
-ea:com.enfusion...

And in a bad run, one time it was decoded as:
-Djava.net.preferIPv4Stack=true
-Dsun.java2d.noddraw=true
-XX:NewSize=128m
-XX:PermSize=128m
-Xmx1glr0���1Behttps___portal.enfusionsystems.com_launcher_https___portal.enfusionsystems.com_launch
-Djnlp.application.href=https://portal.enfusionsystems.com/launcher/launcher.jnlp    

So to sum up:
1) Same cmd line executed in shell works, fails in shortcut
2) When fails, -Djnlpx.vmargs appears truncated and does not decode correctly, resulting in the reported NPE

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Not sure how to get it to actually fail, but happens a lot to myself and many of our clients. Didn't really notice it till moving to Java 8.


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
The ways to recover we have found so far are:
1) Re-download the jnlp from the website, but this seems to only work for that run
2) Remove the application from the Java control panel and re-download jnlp
3) Toggling certain options in the control panel like 'Enable logging' 'Enable trace' cause it to work a few times, then fails.