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
******************************************
