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> wrote: > Send swing-dev mailing list submissions to > swing-dev@openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > 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 > > You can reach the person managing the list at > 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> > To: Matthias Bl?sing <mblaes...@doppel-helix.eu>, > swing-dev@openjdk.java.net > Subject: Re: <Swing Dev> JDK-8189938: Proposed patch > Message-ID: <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 > >>>> > >>>> 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 > > > > > > ------------------------------ > > Message: 2 > Date: Thu, 08 Feb 2018 22:19:51 +0100 > From: Matthias Bl?sing <mblaes...@doppel-helix.eu> > To: Semyon Sadetsky <semyon.sadet...@oracle.com>, > swing-dev@openjdk.java.net > Subject: Re: <Swing Dev> JDK-8189938: Proposed patch > Message-ID: <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> > To: Matthias Bl?sing <mblaes...@doppel-helix.eu>, > swing-dev@openjdk.java.net > Subject: Re: <Swing Dev> JDK-8189938: Proposed patch > Message-ID: <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 > > > > 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 > > > > > -- > Best regards, Sergey. > > > ------------------------------ > > Message: 4 > Date: Thu, 8 Feb 2018 14:42:12 -0800 > From: Semyon Sadetsky <semyon.sadet...@oracle.com> > To: Matthias Bl?sing <mblaes...@doppel-helix.eu>, > swing-dev@openjdk.java.net, Prasanta Sadhukhan > <prasanta.sadhuk...@oracle.com> > Subject: Re: <Swing Dev> JDK-8189938: Proposed patch > Message-ID: <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> > To: Semyon Sadetsky <semyon.sadet...@oracle.com>, Matthias Bl?sing > <mblaes...@doppel-helix.eu>, swing-dev@openjdk.java.net > Subject: Re: <Swing Dev> JDK-8189938: Proposed patch > Message-ID: <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 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 > ****************************************** >
