Created attachment 726 [details]
log with "sun.java2d.d3d=true"

Created attachment 727 [details]
log with "sun.java2d.d3d=false" and "sun.java2d.noddraw=true"

The rudimentary example I put into the wiki doesn't help to reproduce this bug. Please run the unit tests in JOGL (Ant targets "test.manual.run" and "test.auto.run", I did the same for the bug 1078, I need to reproduce it with JOGL and it would help to understand why it happens only the second time that you create a 3D window.

This patch will be helpful for the renderer quirk:
http://forum.jogamp.org/Java-3D-crash-or-flickering-tp4035074p4035085.html

Skipping the ARB contexts is a very bad idea as there's no non ARB context available.

Created attachment 728 [details]
results of test.manual.run

I've attached the results of "test.manual.run". The window that appears at the beginning in empty.
I tried to run "test.auto.run", but I get a series of exceptions saying:
java.lang.UnsatisfiedLinkError: (...)\natives\windows-amd64\gluegen-rt.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform

You can use a 32-bit JVM just to run those tests, it should work even though those errors are annoying.

Created attachment 729 [details]
results of test.manual.run in win32

Results of the auto run:
https://www.dropbox.com/s/o88pekq3ue1gwlu/jogl-2.3-bmanual-20150828-windows-i586-test-results-local.7z?dl=0

(In reply to comment #8)
> Results of the auto run:
> https://www.dropbox.com/s/o88pekq3ue1gwlu/jogl-2.3-bmanual-20150828-windows-
> i586-test-results-local.7z?dl=0

I see no failed test, am I wrong?

(In reply to comment #9)
> (In reply to comment #8)
> > Results of the auto run:
> > https://www.dropbox.com/s/o88pekq3ue1gwlu/jogl-2.3-bmanual-20150828-windows-
> > i586-test-results-local.7z?dl=0
> 
> I see no failed test, am I wrong?

Definitely no failed test for the manual run.
For the auto run, I had to stop the JVM several times as the process was blocked. But apart from that, everything seemed ok.

Here is the simplest test case

Note that the JFrame win line moved before getPreferredConfiguration result in no failure, and without System.setProperty("sun.java2d.noddraw", "true"); nothing fails.

You can also make this fail, by moving the JFrame constructor up and simply calling go twice. 

public static void main(final String[] args)
	{
		System.setProperty("sun.java2d.noddraw", "true");
		go();
	}
public static void go()
{
		
		GraphicsConfiguration config2 = SimpleUniverse.getPreferredConfiguration();
		
		JFrame win = new JFrame("ImageJ 3D Viewer");
		// this constructor before the getPreferredConfiguration call results in no fail
		
		Canvas3D c1 = new Canvas3D(config2);
		SimpleUniverse univ1 = new SimpleUniverse(c1);
		univ1.getViewingPlatform().setNominalViewingTransform();

		BranchGroup scene1 = createSceneGraph();
		univ1.addBranchGraph(scene1);

		JPanel drawingPanel = new JPanel();
		drawingPanel.setLayout(new BorderLayout());
		drawingPanel.setPreferredSize(new Dimension(250, 250));
		drawingPanel.add(univ1.getCanvas(), java.awt.BorderLayout.CENTER);

		win.getContentPane().add(drawingPanel, java.awt.BorderLayout.CENTER);
		win.pack();
		win.setVisible(true);		
	
	}
	

	public static BranchGroup createSceneGraph() {
		BranchGroup objRoot = new BranchGroup();
		TransformGroup objTrans = new TransformGroup();
		objTrans.setCapability(TransformGroup.ALLOW_TRANSFORM_WRITE);
		objRoot.addChild(objTrans);
		objTrans.addChild(new ColorCube(0.4));
		Transform3D yAxis = new Transform3D();
		Alpha rotationAlpha = new Alpha(-1, 4000);

		RotationInterpolator rotator = new RotationInterpolator(rotationAlpha, objTrans, yAxis, 0.0f,
				(float) Math.PI * 2.0f);
		BoundingSphere bounds = new BoundingSphere(new Point3d(0.0, 0.0, 0.0), 100.0);
		rotator.setSchedulingBounds(bounds);
		objRoot.addChild(rotator);
		objRoot.compile();
		return objRoot;
	}

Ok in the class
Win32GraphicsDevice
I see this 

   static {

        // 4455041 - Even when ddraw is disabled, ddraw.dll is loaded when
        // pixel format calls are made.  This causes problems when a Java app
        // is run as an NT service.  To prevent the loading of ddraw.dll
        // completely, sun.awt.nopixfmt should be set as well.  Apps which use
        // OpenGL w/ Java probably don't want to set this.
        String nopixfmt = (String)java.security.AccessController.doPrivileged(
            new sun.security.action.GetPropertyAction("sun.awt.nopixfmt"));
        pfDisabled = (nopixfmt != null);
        initIDs();
    }

so when I add this:
System.setProperty("sun.awt.nopixfmt", "true");
after this
System.setProperty("sun.java2d.noddraw", "true");
in my test case, I no longer get any issues.
However I don't know what effect pfDisabled=true will cause elsewhere

As noted before this only discernible different with the noddraw property true is
Outputs this (false):
getDevice D3DGraphicsDevice[screen=0]
getDevice class name sun.java2d.d3d.D3DGraphicsDevice
instead of this (true):
getDevice Win32GraphicsDevice[screen=0]
getDevice class name sun.awt.Win32GraphicsDevice

and with 

System.setProperty("sun.awt.nopixfmt", "true");

The device is still Win32GraphicsDevice

also
http://stackoverflow.com/questions/507987/how-can-i-make-java3d-start-faster

This bug is now explained in the JoglPipeline, when detected
see
Bug 1333 - Warning notice in cases where Jogl bug 1278 is in effect

So it looks like there will not be a solution only the workaround