On 2/22/2018 3:24 AM, Matthias Bläsing wrote:
Hi again,
I debugged the issue a bit further and I think I tracked it down into
the visual c runtime. What got me curious, was that in any case MTA-COM
initialization had already happend even when a new java thread was
created. So I modified the java launcher (jvm.dll) and inserted
debugging statements into some of the native methods in os_windows.cpp.
I focused on the threading methods. What I found was this:
- create_main_thread, create_os_thread, pd_start_thread all
run with COM not yet initialized
- the native thread initializer (thread_native_entry) is already
running with COM initialized
Every article I read about COM insists, that your are required to
initialize the COM environment on each thread from which you do COM
calls. So there was something fishy.
I looked more into in _beginthreadex and indeed I finally found a lead
on stackoverflow. That pointed me to the sourcecode of threadex.c,
which is part of the Visual Studio 2013 Express Installation.
There you find, that _beginthreadex does not directly start the
supplied thread function, but runs a library initializer
(_threadstartex) first. Part of this initializer reads:
_ptd->_initapartment = __crtIsPackagedApp();
if (_ptd->_initapartment)
{
_ptd->_initapartment = _initMTAoncurrentthread();
}
_callthreadstartex();
__crtIsPackagedApp detects via a kernel function if the application is
run as a "PackagedApp" (i.e. AppX package) and if so, then the
RoInitialize is called, which from my understanding acts like the big
brother of CoInitialize.
Long story short: If your application is build with Visual Studio 2013
and run as a packaged application, you get a broken environment.
I assume that the Oracle JDK 8 binaries are build with an older version
of Visual Studio, which would explain the behavioural differences.
I guess this is roughly what I mentioned in my comment to this bug
https://bugs.openjdk.java.net/browse/JDK-8189938?focusedCommentId=14132002&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14132002
Regards
Prasanta
This looks like it supports my findings:
https://blogs.msdn.microsoft.com/vcblog/2016/07/07/using-visual-c-runtime-in-centennial-project/
Quote from the article:
Note that the existing VC++ 12.0 libraries created during the
Windows 8 timeframe have runtime checks to determine whether the
app is running under the app container or not. When running
desktop apps as a packaged app, these checks might limit the
functionality of the desktop app or cause it to behave like a UWA
(Universal Windows Application) (limited file system access or
create thread initializing MTA etc.). We have fixed this behavior
in the VC++ libraries contained in these framework packages and
thus removing the modern app limitations from your desktop
applications.
So the solution for packagers is:
- Read the above referenced blog
- Install the updated VC 12.0 framework packages for Desktop Bridge
- Install the appropriate contained appx packages (I tested Retail/x64)
- Package again
- Done
After the steps above my test application (a modified version of the
original version from Reinhard) reports, that the COM initialization
has not happend yet and everything is as it should be (initialization
in the JDKs ShellFolder native part is correctly initialized to STA).
=> Yay!
I suspect a java version compiled with a "fixed" version of Visual
Studio (2015 and later) should behave "correctly". It took much effort
not to write what I'm thinking about VS 2013 right now.
If I'm not mistaken the default compiler for future JDKs is about to be
bumped (I think I read something like this on one of the openjdk
mailinglists), so could someone please check if it has happend already?
After literally putting hours into this, I think I will conclude my
investigations here - it was an interesting ride through the JDK build
system, the JDK source and VS documentation.
I hope this helps someone out there
Greetings
Matthias
Am Donnerstag, den 08.02.2018, 19:32 +0100 schrieb Matthias Bläsing:
Hi all,
last month I saw the message from Reinhard Pointer on this list:
http://mail.openjdk.java.net/pipermail/swing-dev/2018-January/008132.
html
referring to this bug:
https://bugs.openjdk.java.net/browse/JDK-8189938
With the instructions given in:
https://bugs.openjdk.java.net/browse/JDK-8193928 (closed as duplicate
of JDK-8189938)
I was able to reproduce the problem on a clean Windows 10
Installation,
as described in the initial report.
The resulting exception leads to my proposed fix:
Could not initialize COM: HRESULT=0x80010106
That HRESULT translates to: RPC_E_CHANGED_MODE
This means, that the COM subsystem is already initialized, but with a
different mode. The code uses CoInitialize and this initializes the
threading module to be apartment threaded. The above HRESULT means
the
thread was already initialized to be multi-threaded.
The mode can't be changed after is was set once, so instead of
bailing
out, I suggest to accept the situation and initialize to be multi-
threaded.
The consequence is that calls from COM to Java could end up on the
wrong thread. A quick look through the code suggest, that COM advises
are not used, so this is a risk that should be taken.
The fix in this case works like this:
* try to initialize COM as it was
* check the return
* if it is RPC_E_CHANGED_MODE, retry initialization als multi-
threaded
* only if that fails raise an exception
One could argue, that if COM is already initialized, you don't need
to
do it yourself, but documentation states, that every successful call
to
CoInitialize/CoInitializeEx must be paired with CoUninitialize.
D3DPipelineManager tracks this in bComInitialized, the other two
callers in the JDK are:
- PLATFORM_API_WinOS_DirectSound.cpp
- ShellFolder2.cpp
Both are covered in the patches. For ShellFolder2 there is an
initialization check, this is modified as described above. And if
both
initialization variant (apartment threaded and multi threaded fail)
this raises an exception.
PLATFORM_API_WinOS_DirectSound is slightly different. The fallback in
the initialization is still done, but no exception is raised in the
error case. This follows the code flow before this change.
I attached the diffs against JDK10 and JDK9 to this email. If they
are
stripped, they can be found here:
http://www.doppel-helix.eu/JDK8189938-openjdk9.diff
http://www.doppel-helix.eu/JDK8189938-openjdk10.diff
I hope this helps with a fix.
Greetings
Matthias
