Dear Prasanta,
The ant script calls the Add-AppxPackage function and fails with
this error message:
"Add-AppxPackage : Deployment failed with HRESULT: 0x80070005,
Access is denied."
Are you running CMD / PowerShell as Administrator? I search for
this error message on Google, and I found a few results were
running as normal user (and not as Administrator) solved the
issue. I've tried again myself as well, and I can easily
reproduce the issue on a newly factory reset Windows 10 machine
with the latest updates running the build via CMD as my normal user.
Greetings,
Reinhard
On 9 February 2018 at 12:58, <swing-dev-requ...@openjdk.java.net
<mailto:swing-dev-requ...@openjdk.java.net>> wrote:
Send swing-dev mailing list submissions to
swing-dev@openjdk.java.net <mailto:swing-dev@openjdk.java.net>
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.openjdk.java.net/mailman/listinfo/swing-dev
<http://mail.openjdk.java.net/mailman/listinfo/swing-dev>
or, via email, send a message with subject or body 'help' to
swing-dev-requ...@openjdk.java.net
<mailto:swing-dev-requ...@openjdk.java.net>
You can reach the person managing the list at
swing-dev-ow...@openjdk.java.net
<mailto:swing-dev-ow...@openjdk.java.net>
When replying, please edit your Subject line so it is more
specific
than "Re: Contents of swing-dev digest..."
Today's Topics:
1. Re: JDK-8189938: Proposed patch (Semyon Sadetsky)
2. Re: JDK-8189938: Proposed patch (Matthias Bl?sing)
3. Re: JDK-8189938: Proposed patch (Sergey Bylokhov)
4. Re: JDK-8189938: Proposed patch (Semyon Sadetsky)
5. Re: JDK-8189938: Proposed patch (Prasanta Sadhukhan)
----------------------------------------------------------------------
Message: 1
Date: Thu, 8 Feb 2018 12:06:04 -0800
From: Semyon Sadetsky <semyon.sadet...@oracle.com
<mailto:semyon.sadet...@oracle.com>>
To: Matthias Bl?sing <mblaes...@doppel-helix.eu
<mailto:mblaes...@doppel-helix.eu>>,
swing-dev@openjdk.java.net <mailto:swing-dev@openjdk.java.net>
Subject: Re: <Swing Dev> JDK-8189938: Proposed patch
Message-ID: <31b2fba0-07dc-3a21-9aab-c19c980df...@oracle.com
<mailto:31b2fba0-07dc-3a21-9aab-c19c980df...@oracle.com>>
Content-Type: text/plain; charset=utf-8; format=flowed
Yet another question. Do you know what might call
CoInitialize in a
different mode? It looks like we use STA everywhere in JDK.
--Semyon
On 02/08/2018 11:55 AM, Semyon Sadetsky wrote:
> I meant the case when MTA COM service is actually used, it
might cause
> issues since the JDK code invokes an another API which assumes
> synchronization. At least performance may be affected.
>
> We don't do separate testing of JDK in MTA mode especially
on the
> regular base. That is why I wouldn't consider MTA mode as
supported.
>
> So, before push the change I would make sure of the
regression test
> suite run in MTA mode hasn't brought any surprises.
>
> --Semyon
>
> On 02/08/2018 11:18 AM, Matthias Bl?sing wrote:
>
>> Resend: I accidentally dropped swing-dev from receivers
(@Semyon I'm
>> subscribed to swing-dev, so we could direct the mails to the
>> mailinglist)
>>
>>
>> Hey Semyon,
>>
>> Am Donnerstag, den 08.02.2018, 10:52 -0800 schrieb Semyon
Sadetsky:
>>> Since you are suggesting to switch from STA to MTA which
>>> consequences
>>> will it have to the current JDK code that was written to
support STA
>>> only?
>> I think there are two questions hidden here:
>>
>> === How does this affect the common codepath taken today? ===
>>
>> It does not. It only changes the behaviour if CoInitalize
fails. So
>> behavioural changes can only occur in environments that
did not work
>> previously.
>>
>> Before this changeset:
>>
>> ? * CoInitialize works => The ShellFolder code can be used
as is
>> ? * CoInitialize failes => The ShellFolder code raises an
exception
>>
>> After this changeset:
>>
>> ? * CoInitialize works => The ShellFolder code can be used
as is
>> ? * CoInitialize failes => retry CoInitializeEx with
multi-threaded
>> ??? apartment
>> ? * if CoInitializeEx fails for multi-threaded apartment
raise exception
>> ??? as before
>>
>> === Is it expected to cause problems in the new code path?
====
>>
>> My understanding of STA vs. MTA is, that it only affects
calls from
>> native to java and not the other way round.
>>
>> To get calls from outside you'd need to install a callback. My
>> understanding is, that you'd need to use an
IConnectionPoint and call
>> its Advise method. I did not spot any such methods.
>>
>> So while I did not go through the whole code base, I think
this
>> changeset should be save.
>>
>> Greetings
>>
>> Matthias
>>
>>> On 02/08/2018 10:32 AM, Matthias Bl?sing wrote:
>>>> referring to this bug:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8189938
<https://bugs.openjdk.java.net/browse/JDK-8189938>
>>>>
>>>> With the instructions given in:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8193928
<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
>
------------------------------
Message: 2
Date: Thu, 08 Feb 2018 22:19:51 +0100
From: Matthias Bl?sing <mblaes...@doppel-helix.eu
<mailto:mblaes...@doppel-helix.eu>>
To: Semyon Sadetsky <semyon.sadet...@oracle.com
<mailto:semyon.sadet...@oracle.com>>,
swing-dev@openjdk.java.net <mailto:swing-dev@openjdk.java.net>
Subject: Re: <Swing Dev> JDK-8189938: Proposed patch
Message-ID: <1518124791.13185.19.ca...@doppel-helix.eu
<mailto:1518124791.13185.19.ca...@doppel-helix.eu>>
Content-Type: text/plain; charset="UTF-8"
Hi,
Am Donnerstag, den 08.02.2018, 12:06 -0800 schrieb Semyon
Sadetsky:
> Yet another question. Do you know what might call
CoInitialize in a
> different mode? It looks like we use STA everywhere in JDK.
I tried to find some documentation how the
FullTrustProcessLauncher of
an UWP application works, but while the MSDN full of
documentation
about UWP, the lifecycle of a native application seems not to be
covered. But my suspicion is this: The launching of an APPX
package
involves the runtime system creating an environment for the
application
and that seems to rely heavily on COM.
So I assume, that COM is initialized outside the java core
and the java
process get this inherited. (But this is speculation!).
I base this on the fact, that CoInitializeEx succeeds and multi
threaded, but fails appartment threaded and the JDK code
holds exactly
three files calling CoInitialize (D2DPipelineManager.cpp,
ShellFolder2.cpp, PLATFORM_API_WinOS_DirectSound.cpp).
> On 02/08/2018 11:55 AM, Semyon Sadetsky wrote:
> > I meant the case when MTA COM service is actually used,
it might cause
> > issues since the JDK code invokes an another API which
assumes
> > synchronization. At least performance may be affected.
> >
> > We don't do separate testing of JDK in MTA mode
especially on the
> > regular base. That is why I wouldn't consider MTA mode as
supported.
> >
> > So, before push the change I would make sure of the
regression test
> > suite run in MTA mode hasn't brought any surprises.
Aggreed and I'd like to help you, but in fact I was happy, that I
managed to compile the JDK on windows and I have zero experience
working on the JDK sources.
As an observation: The COM initialization and usage looked
pretty tight
together in the sources and at least initialization happens
only in the
three files mentioned above. The DirectSound part is even
limit to a
small thread. The ShellFolder2 code looks to be the biggest
direct
user.
Greetings,
Matthias
------------------------------
Message: 3
Date: Thu, 8 Feb 2018 13:58:32 -0800
From: Sergey Bylokhov <sergey.bylok...@oracle.com
<mailto:sergey.bylok...@oracle.com>>
To: Matthias Bl?sing <mblaes...@doppel-helix.eu
<mailto:mblaes...@doppel-helix.eu>>,
swing-dev@openjdk.java.net <mailto:swing-dev@openjdk.java.net>
Subject: Re: <Swing Dev> JDK-8189938: Proposed patch
Message-ID: <340b2b22-4f83-4f16-18bf-7bca181c8...@oracle.com
<mailto:340b2b22-4f83-4f16-18bf-7bca181c8...@oracle.com>>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi, Matthias.
Did you have a chance to find why this code works on
jdk8u152(this is
reported in the bug description).
On 08/02/2018 10:32, Matthias Bl?sing wrote:
> 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
<http://mail.openjdk.java.net/pipermail/swing-dev/2018-January/008132.html>
>
> referring to this bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8189938
<https://bugs.openjdk.java.net/browse/JDK-8189938>
>
> With the instructions given in:
>
> https://bugs.openjdk.java.net/browse/JDK-8193928
<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-openjdk9.diff>
> http://www.doppel-helix.eu/JDK8189938-openjdk10.diff
<http://www.doppel-helix.eu/JDK8189938-openjdk10.diff>
>
> I hope this helps with a fix.
>
> Greetings
>
> Matthias
>
--
Best regards, Sergey.
------------------------------
Message: 4
Date: Thu, 8 Feb 2018 14:42:12 -0800
From: Semyon Sadetsky <semyon.sadet...@oracle.com
<mailto:semyon.sadet...@oracle.com>>
To: Matthias Bl?sing <mblaes...@doppel-helix.eu
<mailto:mblaes...@doppel-helix.eu>>,
swing-dev@openjdk.java.net
<mailto:swing-dev@openjdk.java.net>, Prasanta Sadhukhan
<prasanta.sadhuk...@oracle.com
<mailto:prasanta.sadhuk...@oracle.com>>
Subject: Re: <Swing Dev> JDK-8189938: Proposed patch
Message-ID: <d6211787-1e9f-4a11-8e40-bc7a5083e...@oracle.com
<mailto:d6211787-1e9f-4a11-8e40-bc7a5083e...@oracle.com>>
Content-Type: text/plain; charset=utf-8; format=flowed
On 02/08/2018 01:19 PM, Matthias Bl?sing wrote:
> Hi,
>
> Am Donnerstag, den 08.02.2018, 12:06 -0800 schrieb Semyon
Sadetsky:
>> Yet another question. Do you know what might call
CoInitialize in a
>> different mode? It looks like we use STA everywhere in JDK.
> I tried to find some documentation how the
FullTrustProcessLauncher of
> an UWP application works, but while the MSDN full of
documentation
> about UWP, the lifecycle of a native application seems not
to be
> covered. But my suspicion is this: The launching of an APPX
package
> involves the runtime system creating an environment for the
application
> and that seems to rely heavily on COM.
It looks like there is an internal reason. Probably for UWP
apps only
MTA is allowed because of their life-cycle (the app may be
suspended).
> So I assume, that COM is initialized outside the java core
and the java
> process get this inherited. (But this is speculation!).
>
> I base this on the fact, that CoInitializeEx succeeds and multi
> threaded, but fails appartment threaded and the JDK code
holds exactly
> three files calling CoInitialize (D2DPipelineManager.cpp,
> ShellFolder2.cpp, PLATFORM_API_WinOS_DirectSound.cpp).
>
>> On 02/08/2018 11:55 AM, Semyon Sadetsky wrote:
>>> I meant the case when MTA COM service is actually used,
it might cause
>>> issues since the JDK code invokes an another API which
assumes
>>> synchronization. At least performance may be affected.
>>>
>>> We don't do separate testing of JDK in MTA mode
especially on the
>>> regular base. That is why I wouldn't consider MTA mode as
supported.
>>>
>>> So, before push the change I would make sure of the
regression test
>>> suite run in MTA mode hasn't brought any surprises.
> Aggreed and I'd like to help you, but in fact I was happy,
that I
> managed to compile the JDK on windows and I have zero
experience
> working on the JDK sources.
Prasanta,
since the bug is assigned to you can you test the suggested
fix in MTA
mode and sponsor it if there are no issues?
--Semyon
>
> As an observation: The COM initialization and usage looked
pretty tight
> together in the sources and at least initialization happens
only in the
> three files mentioned above. The DirectSound part is even
limit to a
> small thread. The ShellFolder2 code looks to be the biggest
direct
> user.
>
> Greetings,
> Matthias
------------------------------
Message: 5
Date: Fri, 9 Feb 2018 11:24:30 +0530
From: Prasanta Sadhukhan <prasanta.sadhuk...@oracle.com
<mailto:prasanta.sadhuk...@oracle.com>>
To: Semyon Sadetsky <semyon.sadet...@oracle.com
<mailto:semyon.sadet...@oracle.com>>, Matthias Bl?sing
<mblaes...@doppel-helix.eu
<mailto:mblaes...@doppel-helix.eu>>,
swing-dev@openjdk.java.net <mailto:swing-dev@openjdk.java.net>
Subject: Re: <Swing Dev> JDK-8189938: Proposed patch
Message-ID: <ee194e8a-4995-e80d-cd06-75bac3843...@oracle.com
<mailto:ee194e8a-4995-e80d-cd06-75bac3843...@oracle.com>>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
On 2/9/2018 4:12 AM, Semyon Sadetsky wrote:
> On 02/08/2018 01:19 PM, Matthias Bl?sing wrote:
>
>> Hi,
>>
>> Am Donnerstag, den 08.02.2018, 12:06 -0800 schrieb Semyon
Sadetsky:
>>> Yet another question. Do you know what might call
CoInitialize in a
>>> different mode? It looks like we use STA everywhere in JDK.
>> I tried to find some documentation how the
FullTrustProcessLauncher of
>> an UWP application works, but while the MSDN full of
documentation
>> about UWP, the lifecycle of a native application seems not
to be
>> covered. But my suspicion is this: The launching of an
APPX package
>> involves the runtime system creating an environment for
the application
>> and that seems to rely heavily on COM.
> It looks like there is an internal reason. Probably for UWP
apps only
> MTA is allowed because of their life-cycle (the app may be
suspended).
>> So I assume, that COM is initialized outside the java core
and the java
>> process get this inherited. (But this is speculation!).
>>
>> I base this on the fact, that CoInitializeEx succeeds and
multi
>> threaded, but fails appartment threaded and the JDK code
holds exactly
>> three files calling CoInitialize (D2DPipelineManager.cpp,
>> ShellFolder2.cpp, PLATFORM_API_WinOS_DirectSound.cpp).
>>
>>> On 02/08/2018 11:55 AM, Semyon Sadetsky wrote:
>>>> I meant the case when MTA COM service is actually used,
it might cause
>>>> issues since the JDK code invokes an another API which
assumes
>>>> synchronization. At least performance may be affected.
>>>>
>>>> We don't do separate testing of JDK in MTA mode
especially on the
>>>> regular base. That is why I wouldn't consider MTA mode
as supported.
>>>>
>>>> So, before push the change I would make sure of the
regression test
>>>> suite run in MTA mode hasn't brought any surprises.
>> Aggreed and I'd like to help you, but in fact I was happy,
that I
>> managed to compile the JDK on windows and I have zero
experience
>> working on the JDK sources.
> Prasanta,
>
> since the bug is assigned to you can you test the suggested
fix in MTA
> mode and sponsor it if there are no issues?
>
I am still not able to reproduce in our WIndows 10 Pro
(EN-W10P64-10.0.01.0). "Developer Mode" and "execute
powershell script"
is enabled. This is what I am getting
$ ant clean appx install
Buildfile: D:\prasanta\8189938\JDK-8189938-master\build.xml
clean:
?? [delete] Deleting directory
D:\prasanta\8189938\JDK-8189938-master\bin
?? [delete] Deleting directory
D:\prasanta\8189938\JDK-8189938-master\dist\appx
??? [mkdir] Created dir:
D:\prasanta\8189938\JDK-8189938-master\bin
??? [mkdir] Created dir:
D:\prasanta\8189938\JDK-8189938-master\dist\appx
build:
??? [javac] Compiling 1 source file to
D:\prasanta\8189938\JDK-8189938-master\bin
??? [javac] warning: [options] bootstrap class path not set in
conjunction with -source 9
??? [javac] 1 warning
????? [jar] Building jar:
D:\prasanta\8189938\JDK-8189938-master\dist\appx\main.jar
appx:
???? [copy] Copying 5 files to
D:\prasanta\8189938\JDK-8189938-master\dist\appx
???? [exec] Expected SHA256 checksum:
ffcd6d774cfba78d88a1af253eecad0ec3639bdeabdfb3345e61d1c2355267a4
???? [exec] Actual SHA256 checksum:
ffcd6d774cfba78d88a1af253eecad0ec3639bdeabdfb3345e61d1c2355267a4
???? [exec] Download complete: jre-9.0.4_windows-x64_bin.tar.gz
??? [untar] Expanding:
D:\prasanta\8189938\JDK-8189938-master\jre-9.0.4_windows-x64_bin.tar.gz
into D:\prasanta\8189938\JDK-8189938-master\dist\appx\jre
install:
???? [exec] Add-AppxPackage : Deployment failed with HRESULT:
0x80070005, Access is denied.
???? [exec] Deployment Register operation with target volume
C: on
Package JDK8189938_1.0.0.0_x64__hz258y3tkez3a from:
???? [exec] (AppxManifest.xml)? failed with error
0x80070005. See
http://go.microsoft.com/fwlink/?LinkId=235160
<http://go.microsoft.com/fwlink/?LinkId=235160> for help
???? [exec] diagnosing app deployment issues.
???? [exec] NOTE: For additional information, look for
[ActivityId]
02867602-9e78-0006-8ffb-8802789ed301 in the Event Log or use
???? [exec] the command line Get-AppxLog -ActivityID
02867602-9e78-0006-8ffb-8802789ed301
???? [exec] At line:1 char:1
???? [exec] + Add-AppxPackage -Register
dist/appx/AppxManifest.xml
???? [exec] +
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
???? [exec]???? + CategoryInfo????????? : SecurityError:
(D:\prasanta\818...ppxManifest.xml:String) [Add-AppxPackage],
PSSecurityE
???? [exec]??? xception
???? [exec]???? + FullyQualifiedErrorId :
DeploymentError,Microsoft.Windows.Appx.PackageManager.Commands.AddAppxPackageCommand
???? [exec]
???? [exec] Result: 1
BUILD SUCCESSFUL
Total time: 6 seconds
ARAPTE-PC+client@ARAPTE-PC
/cygdrive/d/prasanta/8189938/JDK-8189938-master
$ ls
appx? bin? build.xml? dist? get-java.ps1
jre-9.0.4_windows-x64_bin.tar.gz? LICENSE? README.md
screenshot.png? src
ARAPTE-PC+client@ARAPTE-PC
/cygdrive/d/prasanta/8189938/JDK-8189938-master
$ JDK8189938
bash: JDK8189938: command not found
Regards
Prasanta
> --Semyon
>>
>> As an observation: The COM initialization and usage looked
pretty tight
>> together in the sources and at least initialization
happens only in the
>> three files mentioned above. The DirectSound part is even
limit to a
>> small thread. The ShellFolder2 code looks to be the
biggest direct
>> user.
>>
>> Greetings,
>> Matthias
>
End of swing-dev Digest, Vol 130, Issue 13
******************************************
