<AWT Dev> Regression test failure loading a DLL

[Pete Brunet]

Where is the right place to get a review of my test case?  I'll post it
here a bit later if there's not a better idea.

On 12/18/13 2:01 PM, Pete Brunet wrote:
> On 12/18/13 1:22 PM, Pete Brunet wrote:
>> On 12/18/13 1:15 PM, Pete Brunet wrote:
>>> On 12/18/13 3:24 AM, Artem Ananiev wrote:
>>>> On 12/17/2013 10:42 PM, Pete Brunet wrote:
>>>>> Hi Anthony, Thanks again for the assistance!
>>>>>
>>>>> On 12/17/13 7:29 AM, Anthony Petrov wrote:
>>>>>>> Immediate load in JAWT*, delay load in Java*
>>>>>> Why is that? Can you try re-linking the JAWTAccessBridge.DLL so that
>>>>>> it uses delayed libs loading (which is always a good thing) and see if
>>>>>> this changes anything?
>>>>> Maybe it's a Dependency Walker anomaly?  I got that info from the fact
>>>>> that Dependency Walker shows an hour glass next to the red icon for
>>>>> ole32.dll for Java*.dll but not for ole32.dll for JAWT*.dll.  (Also when
>>>>> I ran it today oleaut32.dll was delay load in both.)  I looked through
>>>>> the ole32.dll entries in the trees for both DLLs and didn't find any
>>>>> differences.
>>>>>
>>>>> When I load JAWT*.dll Dependency Walker reports an error (and some
>>>>> warnings).  If I add bin\server to its search list that error goes away
>>>>> (and the warnings remain).
>>>>>
>>>>> I found the build statements in jdk8\jdk\make\lib\PlatformLibraries.gmk
>>>>> and Java* vs JAWT* are almost the same.  Here is are the statments in
>>>>> the gmk file for JAWT* and Java* with the two significant difference
>>>>> noted.
>>>>>
>>>>> $(call SetupNativeCompilation,BUILD_JAWTACCESSBRIDGE$1, \
>>>>>            LIBRARY = JAWTAccessBridge$1, \
>>>>>            OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
>>>>>            SRC := $(ACCESSBRIDGE_SRCDIR), \
>>>>>            INCLUDE_FILES := JAWTAccessBridge.cpp, \ <-- different list
>>>>> for Java*
>>>>>            LANG := C++, \
>>>>>            OPTIMIZATION := LOW, \
>>>>>            CFLAGS := $(CFLAGS_JDKLIB) \
>>>>>                -DACCESSBRIDGE_ARCH_$3, \
>>>>>            LDFLAGS := $(LDFLAGS_JDKLIB) kernel32.lib user32.lib
>>>>> gdi32.lib \
>>>>>                winspool.lib jawt.lib comdlg32.lib advapi32.lib
>>>>> shell32.lib \  <-- jawt.lib added
>>>> Let me ask a stupid question: does pre-loading jawt.dll before
>>>> JAWTAccessBridge.dll help?
>>> It didn't help but it's interesting that the failure now happens when
>>> jawt.dll is loaded.
>> Loading awt.dll before jawt.dll before JAWTAccessBridge-32.dll solved
>> the problem.  But why?
> Normally JAWTAccessBridge-32.dll is loaded by this sequence:  the access
> bridge class is loaded by the VM (if the users's
> .accessibility.properties is set up for that), then that class loads
> JAWTAccessBridge-32.dll which I assume then loads jawt.dll which loads
> awt.dll.  The Win dll search algorithm found here:
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx
> looks in the app directory which I assume in the normal case has been
> set to the jre's bin directory.  In the case of running my test case
> under jtreg the app directory and current directory are probably not the
> jre's bin directory.  So I suppose it's OK with respect to what I want
> to accomplish with my test case for me to preload awt.dll and jawt.dll
> in the test case.
>>>>>                ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib \
>>>>>                -subsystem:windows -machine:$2 \
>>>>>                -def:$(ACCESSBRIDGE_SRCDIR)/JAWTAccessBridge.DEF, \
>>>>>            VERSIONINFO_RESOURCE :=
>>>>> $(ACCESSBRIDGE_SRCDIR)/AccessBridgeStatusWindow.rc, \
>>>>>            RC_FLAGS := $(RC_FLAGS), \
>>>>>            OBJECT_DIR := $(JDK_OUTPUTDIR)/objs/libjawtaccessbridge$1, \
>>>>>            DEBUG_SYMBOLS := true)
>>>>>
>>>>>   $(call SetupNativeCompilation,BUILD_JAVAACCESSBRIDGE$1, \
>>>>>            LIBRARY = JavaAccessBridge$1, \
>>>>>            OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
>>>>>            SRC := $(ACCESSBRIDGE_SRCDIR), \
>>>>>            INCLUDE_FILES := AccessBridgeATInstance.cpp
>>>>> AccessBridgeDebug.cpp \
>>>>>                AccessBridgeJavaEntryPoints.cpp \
>>>>>                AccessBridgeMessages.cpp JavaAccessBridge.cpp, \
>>>>>            LANG := C++, \
>>>>>            OPTIMIZATION := LOW, \
>>>>>            CFLAGS := $(CFLAGS_JDKLIB) \
>>>>>                -DACCESSBRIDGE_ARCH_$3, \
>>>>>            LDFLAGS := $(LDFLAGS_JDKLIB) kernel32.lib user32.lib
>>>>> gdi32.lib \
>>>>>                winspool.lib comdlg32.lib advapi32.lib shell32.lib \
>>>>>                ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib \
>>>>>                -subsystem:windows -machine:$2 \
>>>>>                -def:$(ACCESSBRIDGE_SRCDIR)/JavaAccessBridge.DEF, \
>>>>>            VERSIONINFO_RESOURCE :=
>>>>> $(ACCESSBRIDGE_SRCDIR)/AccessBridgeStatusWindow.rc, \
>>>>>            RC_FLAGS := $(RC_FLAGS), \
>>>>>            OBJECT_DIR := $(JDK_OUTPUTDIR)/objs/libjavaaccessbridge$1, \
>>>>>            DEBUG_SYMBOLS := true)
>>>>>
>>>>> I wonder if the LDFLAGS lists are right.  Dependency Walker shows the
>>>>> first level dependencies as follows:
>>>>> - JAWT*.dll: jawt.dll, msvcr100.dll, kernel32.dll
>>>>> - Java*.dll: msvcr100.dll, kernel32.dll, user32.dll
>>>>> but the LDFLAGS lists are much longer and also both are missing
>>>>> msvcr100.lib
>>>> msvcr100.dll is loaded by Java launcher from JRE/bin directory, so
>>>> it's not a problem.
>>>>
>>>>> I ran the make in debug mode to get more output and the linker flags are
>>>>> the same, except for the former including jawt.lib
>>>>>
>>>>> For JAWT*:
>>>>> LDFLAGS := -nologo -opt:ref -incremental:no -safeseh -debug -dll
>>>>> -libpath:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/jdk/lib
>>>>>
>>>>> kernel32.lib user32.lib gdi32.lib winspool.lib jawt.lib comdlg32.lib
>>>>> advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib
>>>>> odbccp32.lib -subsystem:windows -machine:I386
>>>>> -def:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/jdk/src/closed/windows/native/sun/bridge/JAWTAccessBridge.DEF
>>>>>
>>>>>
>>>>> For Java*:
>>>>> LDFLAGS := -nologo -opt:ref -incremental:no -safeseh -debug -dll
>>>>> -libpath:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/jdk/lib
>>>>>
>>>>> kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib
>>>>> shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
>>>>> -subsystem:windows -machine:I386
>>>>> -def:/cygdrive/c/Users/Pete/JDK8/JDK-8029691/jdk8/jdk/src/closed/windows/native/sun/bridge/JavaAccessBridge.DEF
>>>>>
>>>>>
>>>>> Note that some builds have a LDFLAGS_SUFFIX_windows with -DELAYLOAD, but
>>>>> these bridge builds don't.  I'll try adding this after lunch.
>>>>>
>>>>> Regarding the source code JAWTAccessBridge.cpp doesn't load any DLLs.
>>>>> JavaAccessBridge.cpp has a loadlibrary of jawt.dll (and none of the
>>>>> other included source files load DLLs).
>>>>>
>>>>> In the middle of all these details I don't want to loose track of the
>>>>> fact that the problem only occurs when using jtreg.  In normal use there
>>>>> has never been a problem.
>>>>>> Also,
>>>>>>> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>>>> These dependencies are also fine, at least I see the same dlls in the
>>>> list of awt.dll dependencies, and it doesn't cause any troubles.
>>>>
>>>>>> JDK doesn't support WinRT currently. The JAWT* (or any binary in JDK)
>>>>>> just shouldn't be linked against these libraries (and probably other
>>>>>> API-MS-*, too). Where do the dependencies come from? What does your
>>>>>> Makefile do to link the JAWT* lib?
>>>>> The JAWT* questions is answered above.
>>>>>
>>>>> This is the tree I see for the WinRT DLLs you mentioned:
>>>>> javaaccessbridge.dll
>>>>>    user32.dll
>>>>>      advapi32.dll
>>>>>        wintrust.dll
>>>>>          crypt32.dll
>>>>>            userenv.dll
>>>>>              shell32.dll
>>>>>                wininet.dll
>>>>>                  iertutil.dll
>>>>>                    API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL and
>>>>>                    API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>>>>>
>>>>> ditto to
>>>>>    shell32.dll
>>>>>      shdocvw.dll
>>>>>        ieframe.dll
>>>>>          mshtml.dll
>>>>>            API-MS-WIN-CORE-WINRT-L1-1-0.DLL and
>>>>>            API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>>>> -- 
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 12/17/2013 12:44 AM, Pete Brunet wrote:
>>>>>>> Hi Anthony, Thanks for helping...
>>>>>>>
>>>>>>> On 12/16/13 1:32 PM, Anthony Petrov wrote:
>>>>>>>> Hi Pete,
>>>>>>>>
>>>>>>>> I see you've already tried the Dependency Walker.
>>>>>>>>
>>>>>>>> 1. Could you please clarify the following: if you compile two
>>>>>>>> lists of
>>>>>>>> dependencies, one for JavaAccessBridge.dll and another for
>>>>>>>> JAWTAccessBridge.DLL, and compare them, are there any differences?
>>>>>>> Differences:
>>>>>>>
>>>>>>> JAWT* has these extras
>>>>>>> jvm.dll - error opening file
>>>>>>> awt.dll - no problem with this and the following
>>>>>>> java.dll
>>>>>>> jawt.dll
>>>>>>> verify.dll
>>>>>>>
>>>>>>> Immediate load in JAWT*, delay load in Java*
>>>>>>> ole32 - colored red, i.e. missing export function required by parent
>>>>>>> module
>>>>>>> oleaut32.dll - no problem
>>>>>>>> 2. If you change the order of loading the libraries, will it fail
>>>>>>>> right away w/o even loading the JavaAccessBridge.dll ?
>>>>>>> yes
>>>>>>>> 3. If the above doesn't help, please post the full list of
>>>>>>>> dependencies for JAWTAccessBridge.DLL as reported by the Dependency
>>>>>>>> Walker.
>>>>>>> Error opening file:
>>>>>>> JVM.DLL
>>>>>>> API-MS-WIN-CORE-COM-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
>>>>>>> API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
>>>>>>> DCOMP.DLL
>>>>>>> GPSVC.DLL
>>>>>>> IESHIMS.DLL
>>>>>>> Red (missing export function required by parent module):
>>>>>>> API-MS-WIN-CORE-THREADPOOL-L1-1-0.DLL
>>>>>>> OLE32.DLL
>>>>>>> Red, delay load:
>>>>>>> DWMAPI.DLL
>>>>>>> IEFRAME.DLL
>>>>>>> IMM32.DLL
>>>>>>> MFPLAT.DLL
>>>>>>> NDFAPI.DLL
>>>>>>> USERENV.DLL
>>>>>>> UXTHEME.DLL
>>>>>>> No problems:
>>>>>>> ADVAPI32.DLL
>>>>>>> API-MS-WIN-CORE-CONSOLE-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-DATETIME-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-DEBUG-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-DELAYLOAD-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-ERRORHANDLING-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-FIBERS-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-FILE-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-HANDLE-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-HEAP-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-INTERLOCKED-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-IO-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-LIBRARYLOADER-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-LOCALIZATION-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-LOCALREGISTRY-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-MEMORY-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-MISC-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-NAMEDPIPE-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-PROCESSENVIRONMENT-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-PROCESSTHREADS-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-PROFILE-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-RTLSUPPORT-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-STRING-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-SYNCH-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-SYSINFO-L1-1-0.DLL
>>>>>>> API-MS-WIN-CORE-UTIL-L1-1-0.DLL
>>>>>>> API-MS-WIN-SECURITY-BASE-L1-1-0.DLL
>>>>>>> API-MS-WIN-SECURITY-LSALOOKUP-L1-1-0.DLL
>>>>>>> API-MS-WIN-SERVICE-CORE-L1-1-0.DLL
>>>>>>> API-MS-WIN-SERVICE-MANAGEMENT-L1-1-0.DLL
>>>>>>> API-MS-WIN-SERVICE-MANAGEMENT-L2-1-0.DLL
>>>>>>> API-MS-WIN-SERVICE-WINSVC-L1-1-0.DLL
>>>>>>> AWT.DLL
>>>>>>> CRYPTBASE.DLL
>>>>>>> GDI32.DLL
>>>>>>> JAVA.DLL
>>>>>>> JAWT.DLL
>>>>>>> JAWTACCESSBRIDGE.DLL
>>>>>>> KERNEL32.DLL
>>>>>>> KERNELBASE.DLL
>>>>>>> LPK.DLL
>>>>>>> MSVCR100.DLL
>>>>>>> MSVCRT.DLL
>>>>>>> NTDLL.DLL
>>>>>>> OLEAUT32.DLL
>>>>>>> RPCRT4.DLL
>>>>>>> SSPICLI.DLL
>>>>>>> USER32.DLL
>>>>>>> USP10.DLL
>>>>>>> VERIFY.DLL
>>>>>>> ACLUI.DLL
>>>>>>> ACTIVEDS.DLL
>>>>>>> ADSLDPC.DLL
>>>>>>> ADVPACK.DLL
>>>>>>> API-MS-WIN-DOWNLEVEL-ADVAPI32-L1-1-0.DLL
>>>>>>> API-MS-WIN-DOWNLEVEL-ADVAPI32-L2-1-0.DLL
>>>>>>> API-MS-WIN-DOWNLEVEL-NORMALIZ-L1-1-0.DLL
>>>>>>> API-MS-WIN-DOWNLEVEL-OLE32-L1-1-0.DLL
>>>>>>> API-MS-WIN-DOWNLEVEL-SHELL32-L1-1-0.DLL
>>>>>>> API-MS-WIN-DOWNLEVEL-SHLWAPI-L1-1-0.DLL
>>>>>>> API-MS-WIN-DOWNLEVEL-SHLWAPI-L2-1-0.DLL
>>>>>>> API-MS-WIN-DOWNLEVEL-USER32-L1-1-0.DLL
>>>>>>> API-MS-WIN-DOWNLEVEL-VERSION-L1-1-0.DLL
>>>>>>> API-MS-WIN-SECURITY-SDDL-L1-1-0.DLL
>>>>>>> APPHELP.DLL
>>>>>>> ATL.DLL
>>>>>>> AUTHZ.DLL
>>>>>>> AVRT.DLL
>>>>>>> BCRYPT.DLL
>>>>>>> BROWCLI.DLL
>>>>>>> CABINET.DLL
>>>>>>> CERTCLI.DLL
>>>>>>> CERTENROLL.DLL
>>>>>>> CFGMGR32.DLL
>>>>>>> CLBCATQ.DLL
>>>>>>> COMCTL32.DLL
>>>>>>> COMCTL32.DLL
>>>>>>> COMDLG32.DLL
>>>>>>> CREDUI.DLL
>>>>>>> CRYPT32.DLL
>>>>>>> CRYPTSP.DLL
>>>>>>> CRYPTUI.DLL
>>>>>>> CSCAPI.DLL
>>>>>>> D2D1.DLL
>>>>>>> D3D11.DLL
>>>>>>> DAVHLPR.DLL
>>>>>>> DBGHELP.DLL
>>>>>>> DEVMGR.DLL
>>>>>>> DEVOBJ.DLL
>>>>>>> DEVRTL.DLL
>>>>>>> DFSCLI.DLL
>>>>>>> DHCPCSVC.DLL
>>>>>>> DHCPCSVC6.DLL
>>>>>>> DNSAPI.DLL
>>>>>>> DRVSTORE.DLL
>>>>>>> DSROLE.DLL
>>>>>>> DUI70.DLL
>>>>>>> DUSER.DLL
>>>>>>> DWRITE.DLL
>>>>>>> DXGI.DLL
>>>>>>> EAPPCFG.DLL
>>>>>>> EAPPPRXY.DLL
>>>>>>> EFSADU.DLL
>>>>>>> EFSUTIL.DLL
>>>>>>> ELSCORE.DLL
>>>>>>> ESENT.DLL
>>>>>>> FMS.DLL
>>>>>>> GDIPLUS.DLL
>>>>>>> GPAPI.DLL
>>>>>>> HLINK.DLL
>>>>>>> IEADVPACK.DLL
>>>>>>> IERTUTIL.DLL
>>>>>>> IEUI.DLL
>>>>>>> IMAGEHLP.DLL
>>>>>>> IMGUTIL.DLL
>>>>>>> INETCOMM.DLL
>>>>>>> IPHLPAPI.DLL
>>>>>>> LINKINFO.DLL
>>>>>>> LOGONCLI.DLL
>>>>>>> MFC42U.DLL
>>>>>>> MLANG.DLL
>>>>>>> MMDEVAPI.DLL
>>>>>>> MPR.DLL
>>>>>>> MPRAPI.DLL
>>>>>>> MPRMSG.DLL
>>>>>>> MSASN1.DLL
>>>>>>> MSCTF.DLL
>>>>>>> MSFEEDS.DLL
>>>>>>> MSHTML.DLL
>>>>>>> MSI.DLL
>>>>>>> MSILTCFG.DLL
>>>>>>> MSIMG32.DLL
>>>>>>> MSLS31.DLL
>>>>>>> MSOERT2.DLL
>>>>>>> MSRATING.DLL
>>>>>>> MSSIGN32.DLL
>>>>>>> NCRYPT.DLL
>>>>>>> NETAPI32.DLL
>>>>>>> NETBIOS.DLL
>>>>>>> NETJOIN.DLL
>>>>>>> NETPLWIZ.DLL
>>>>>>> NETUTILS.DLL
>>>>>>> NEWDEV.DLL
>>>>>>> NORMALIZ.DLL
>>>>>>> NSI.DLL
>>>>>>> NTDSAPI.DLL
>>>>>>> NTSHRUI.DLL
>>>>>>> OCCACHE.DLL
>>>>>>> ODBC32.DLL
>>>>>>> OLEACC.DLL
>>>>>>> OLEDLG.DLL
>>>>>>> ONEX.DLL
>>>>>>> PCWUM.DLL
>>>>>>> POWRPROF.DLL
>>>>>>> PRINTUI.DLL
>>>>>>> PRNTVPT.DLL
>>>>>>> PROFAPI.DLL
>>>>>>> PROPSYS.DLL
>>>>>>> PSAPI.DLL
>>>>>>> PUIAPI.DLL
>>>>>>> RASAPI32.DLL
>>>>>>> RASDLG.DLL
>>>>>>> RASMAN.DLL
>>>>>>> REGAPI.DLL
>>>>>>> RSTRTMGR.DLL
>>>>>>> RTUTILS.DLL
>>>>>>> SAMCLI.DLL
>>>>>>> SAMLIB.DLL
>>>>>>> SCECLI.DLL
>>>>>>> SECUR32.DLL
>>>>>>> SENSAPI.DLL
>>>>>>> SETUPAPI.DLL
>>>>>>> SHDOCVW.DLL
>>>>>>> SHELL32.DLL
>>>>>>> SHLWAPI.DLL
>>>>>>> SLC.DLL
>>>>>>> SPFILEQ.DLL
>>>>>>> SPINF.DLL
>>>>>>> SPPC.DLL
>>>>>>> SRVCLI.DLL
>>>>>>> TAPI32.DLL
>>>>>>> UIAUTOMATIONCORE.DLL
>>>>>>> URLMON.DLL
>>>>>>> VAULTCLI.DLL
>>>>>>> VERSION.DLL
>>>>>>> VPNIKEAPI.DLL
>>>>>>> W32TOPL.DLL
>>>>>>> WDI.DLL
>>>>>>> WEBIO.DLL
>>>>>>> WEBSERVICES.DLL
>>>>>>> WER.DLL
>>>>>>> WERUI.DLL
>>>>>>> WINBRAND.DLL
>>>>>>> WINDOWSCODECS.DLL
>>>>>>> WINHTTP.DLL
>>>>>>> WININET.DLL
>>>>>>> WINMM.DLL
>>>>>>> WINNSI.DLL
>>>>>>> WINSCARD.DLL
>>>>>>> WINSPOOL.DRV
>>>>>>> WINSTA.DLL
>>>>>>> WINTRUST.DLL
>>>>>>> WKSCLI.DLL
>>>>>>> WLANAPI.DLL
>>>>>>> WLANUTIL.DLL
>>>>>>> WLDAP32.DLL
>>>>>>> WS2_32.DLL
>>>>>>> WTSAPI32.DLL
>>>>>>> XMLLITE.DLL
>>>>>>>> -- 
>>>>>>>> best regards,
>>>>>>>> Anthony
>>>>>>>>
>>>>>>>> On 12/16/2013 08:02 PM, Pete Brunet wrote:
>>>>>>>>> I'm writing a regression test and it is failing trying to load
>>>>>>>>> bin\JAWTAccessBridge.DLL.  It was successful in loading
>>>>>>>>> bin\JavaAccessBridge.dll just prior to the failure.  These two DLLs
>>>>>>>>> are
>>>>>>>>> in jre\bin.  Here's the failure:
>>>>>>>>>
>>>>>>>>> java.lang.UnsatisfiedLinkError:
>>>>>>>>> C:\\Users\\Pete\\JDK8\\JDK-8029691\\jdk8\\build\\windows-x86-normal-server-release\\images\\j2sdk-image\\jre\\bin\\JAWTAccessBridge.dll:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Can't find dependent libraries
>>>>>>>>>     at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>>>>>>>>>     at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929)
>>>>>>>>>     at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835)
>>>>>>>>>     at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>>>>>>>>>     at java.lang.System.loadLibrary(System.java:1119)
>>>>>>>>>     at JABDLL$4.run(JABDLL.java:116)
>>>>>>>>>     at java.security.AccessController.doPrivileged(Native Method)
>>>>>>>>>     at JABDLL.foundLegacyDLLs(JABDLL.java:113)
>>>>>>>>>     at JABDLL.main(JABDLL.java:67)
>>>>>>>>>     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:483)
>>>>>>>>>     at
>>>>>>>>> com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     at java.lang.Thread.run(Thread.java:744)
>>>>>>>>>
>>>>>>>>> Here's the pertinent code:
>>>>>>>>>
>>>>>>>>> private static boolean foundLegacyDLLs() {
>>>>>>>>>                java.security.AccessController.doPrivileged(
>>>>>>>>>                    new java.security.PrivilegedAction() {
>>>>>>>>>                        public Object run() {
>>>>>>>>>                            System.loadLibrary("JavaAccessBridge");
>>>>>>>>>                            return null;
>>>>>>>>>                        }
>>>>>>>>>                    }, null, new
>>>>>>>>> RuntimePermission("loadLibrary.JavaAccessBridge")
>>>>>>>>>                );
>>>>>>>>>                java.security.AccessController.doPrivileged(
>>>>>>>>>                    new java.security.PrivilegedAction() {
>>>>>>>>>                        public Object run() {
>>>>>>>>>                           
>>>>>>>>> System.loadLibrary("JAWTAccessBridge");  //
>>>>>>>>> line
>>>>>>>>> 116, fails here
>>>>>>>>>                            return null;
>>>>>>>>>                        }
>>>>>>>>>                    }, null, new
>>>>>>>>> RuntimePermission("loadLibrary.JAWTAccessBridge")
>>>>>>>>>                );
>>>>>>>>>                return true;
>>>>>>>>>        }
>>>>>>>>>
>>>>>>>>> Here's the jtreg run:
>>>>>>>>>
>>>>>>>>> $ /cygdrive/c/Users/Pete/JDK8/jtreg/win32/bin/jtreg
>>>>>>>>> -testjdk:/Users/Pete/JDK8/JDK-8029691/jdk8/build/windows-x86-normal-server-release/images/j2sdk-image
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -verbose:summary closed/com/sun/java/accessibility/JABDLL.java
>>>>>>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\TEST.groups: group
>>>>>>>>> needs_jre: file not found: java/text/Bidi/Bug6665028.java  // assume
>>>>>>>>> this can be ignored
>>>>>>>>> FAILED: closed/com/sun/java/accessibility/JABDLL.java
>>>>>>>>> Test results: failed: 1
>>>>>>>>> Report written to
>>>>>>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTreport\html\report.html
>>>>>>>>>
>>>>>>>>> Results written to
>>>>>>>>> C:\Users\Pete\JDK8\JDK-8029691\jdk8\jdk\test\JTwork
>>>>>>>>> Error: Some tests failed or other problems occurred.
>>>>>>>>>
>>>>>>>>> Here's the prolog to the test case:
>>>>>>>>>
>>>>>>>>> /*
>>>>>>>>>      * @test
>>>>>>>>>      * @summary ...
>>>>>>>>>      * @run main JABDLL
>>>>>>>>>      */
>>>>>>>>>
>>>>>>>>> The built image runs fine in normal use, i.e. I can run SwingSet2
>>>>>>>>> with
>>>>>>>>> the same image so I assume it's something I'm not doing right with
>>>>>>>>> respect to jtreg.
>>>>>>>>>
>>>>>>>>> The dependency walker reports jvm.dll which is in bin\server.  I
>>>>>>>>> tried
>>>>>>>>> moving that to bin but that didn't help.   Also some Win DLLs were
>>>>>>>>> reported most of which start with API-MS-WIN- but I assume those are
>>>>>>>>> false negatives.  The sdk image I am testing is 32 bit and the
>>>>>>>>> DLL is
>>>>>>>>> also 32 bit.  Hopefully it's just something I don't yet understand
>>>>>>>>> about
>>>>>>>>> jprt, like maybe a missing @ tag in the prolog.
>>>>>>>>>
>>>>>>>>> Any ideas on how to debug this?
>>>>>>>>>
>>>>>>>>> Pete
>>>>>>>>>
>>>>>>>>>