Hi Prasanta, Thanks for looking into this issue. When doing Windows development, the Event Log is sometimes quite useful. The error output hints at some additional information in the Windows Event Log. Have you had a look to see if there's any hints as to why it's not working on your test machine?
>> NOTE: For additional information, look for *[ActivityId] 02867602-9e78-0006-8ffb-8802789ed301 in the Event Log* or use the command line *Get-AppxLog -ActivityID 02867602-9e78-0006-8ffb-8802789ed301* Kind Regards, Reinhard On 9 February 2018 at 16:23, Prasanta Sadhukhan < prasanta.sadhuk...@oracle.com> wrote: > Hi Reinhard, > Yes, I was running as a Administrator. But, I created another Standard > user and login through that but I still get the same problem. > > Regards > Prasanta > On 2/9/2018 12:09 PM, Reinhard Pointner wrote: > > 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-Januar >> y/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-818993 >> 8-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-818993 >> 8-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.Comman >> ds.AddAppxPackageCommand >> ???? [exec] >> ???? [exec] Result: 1 >> >> BUILD SUCCESSFUL >> Total time: 6 seconds >> >> ARAPTE-PC+client@ARAPTE-PC /cygdrive/d/prasanta/8189938/J >> DK-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/J >> DK-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 >> ****************************************** >> > > >
