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