Qubes Windows Tools (QWT) on R4

[ghost]

!! EDIT Feb. 2022 !!

• QWT works with R4.0 and R4.1 thanks to the work of @jevank et al. so most of this post is outdated (there are a few minor outstanding issues but the main stuff - copy/paste, copy files, ... - works).
• QWT is on its way to be available as a qubes rpm package (contrib or official).
• See this wiki forum post for a quick installation howto and contributed user reports about what works and what doesn't with various windows versions.
• QWT: github repo, issues, binaries

!! THE CONTENT BELOW IS OUTDATED !!!

See Marek's comment (some issues remain); install with

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools

Note however that upgrading from QWT3 often fails (see below), and installing QWT4 in clean windows HVMs doesn't work for some users. Clone your VM before attempting anything !

• 1st install: follow the official doc
• upgrade from the 3.2 version: clone your vm first ! ; temporarily set debug to true and qrexec_timeout to a large value (eg. 600) or the vm will be killed before you'll be able to complete the setup (it takes a bit of point&click).
  • [FAILS] VM with SP1 and no other windows updates / upgrading over 3.2: at the following reboot, windows fails to boot and tries to repair files, which as usual doesn't fix anything (the VM might boot at some point, without the tools installed)
  • [TODO] VM with SP1 and no other windows updates / remove 3.2 version first and then install 4.0.0
  • [TODO] VM with latest windows updates / upgrade over 3.2
  • [TODO] VM with latest windows updates / remove 3.2 version first and then install 4.0.0

---

[The purpose of this issue is to gather user experience and document the installation of R3.2's QWT in Windows HVMs on R4, bugs found and workarounds until the tools are fixed (and hopefully have a new maintainer).]

Qubes OS version:

Qubes 4.0

Affected TemplateVMs:

Windows HVMs

Edits (2018)

• Nov 13
  • add gateway network setting in issue 1
• June 23
  • add @mossy-nw 's comment about properly checking the rpm sig
• May 7
  • add note about VM qvm-prefs issue when creating a VM based on a windows template
• Apr 23
  • add AppVM based on win TemplateVM issue
• Mar 11
  • revert note about qvm-copy/move failing, it works fine (transient errors because of update mismatch on my system).
• Mar 5
  • add note that since qsb #38 qvm-copy/move fails with 'request refused' because the tools aren't updated.
  • add qvm-prefs vmname default_user to fix copy location ; reference here
• Feb 28
  • add rpm -K for rpm sig check (seen such questions in qubes-users ML)
  • add comment by @AJolly / QWT won't install with the 'move profiles' option disabled
• Feb 18
  • more info on networking (DNS ips, ... + disabling the qubes net service)
  • copied some of the commands needed from the official QWT install guide
  • note about windows update + Xen VBD driver

---

QWT installation

Prerequisite: win7 x64 VM (see https://www.qubes-os.org/doc/windows-vm/).

Get the last QWT rpm here.

In order to check the rpm's signature you'll have to import Qubes Release 3 Signing Key in the VM where you are confirming the rpm signature. Get the key here .

Check the key fingerprint as follows:

gpg2 --fingerprint --import --import-options show-only --dry-run qubes-release-3-signing-key.asc

Or alternatively,

gpg2 --import qubes-release-3-signing-key.asc
gpg2 --fingerprint "Qubes OS Release 3"

And compare with the key's well-known fingerprint, which should be C522 61BE 0A82 3221 D94C A1D1 CB11 CA1D 03FA 5082

Import the key to the VM's rpm keyring:

sudo rpm --import qubes-release-3-signing-key.asc

You can now check the rpm's signature (more info on rpm signatures here):

rpm -K qubes-windows-tools-3.2.2-3.x86_64.rpm

You should get qubes-windows-tools-3.2.2-3.x86_64.rpm: digests signatures OK. If not, check that the rpm is properly downloaded, that the signing key is imported, ...

Extract the iso from the rpm:

rpm2cpio qubes-windows-tools-3.2.2-3.x86_64.rpm | cpio -idmv

And start the VM (assuming the iso is in the 'untrusted' VM):

qvm-start --cdrom=untrusted:/home/user/qubes-windows-tools.iso win7new

From the QWT install guide:

• win cmd: bcdedit /set testsigning on
• win cmd: netplwiz / uncheck 'Users must enter a user name and password...'
• in dom0: qvm-prefs vmname qrexec_timeout 300

Note about Windows Update:

• updating the machine is not required provided you don't enable the storage driver (disabled by default) in QWT' setup. QWT works on a bare SP1 install as well as in fully updated. See @dmoerner's comment below on how to install updates.
• however, a fully updated Windows seems to be required in order to install xen's VBD (storage) PV driver:
  • on "stock" SP1, installing Xen's PV driver from either QWT or from Xen's official site results in either a BSOD or endless unfixable reboots.
  • after a full Windows Update (takes hours), installing Xen's official driver works flawlessly. Haven't tested when installing QWT with the storage PV driver after updates.

Note about QWT's 'move user profiles' options: @AJolly reports that QWT wouldn't install with the option disabled.

Issue 1 - Networking isn't set up properly

The PV adapter's status is stuck at "Identifying"; pinging an ip works but pinging a host fails, indicating a problem with DNS resolution. A tcpdump on sys-firewall indeed shows that DNS requests are sent to the gateway's ip and are rejected. The reason is that in R4 VMs are now using the exposed "/qubes-{primary,secondary}-dns" values, while R3.2's Windows Tools still use /qubes-gateway (whose IP in R4 is different from /qubes-primary-dns).

Workaround: disable the "Qubes Network Setup" service (with gui/msconfig, or sc config "QubesNetworkSetup" start= disabled in a command prompt) and configure the network manually.

Settings:

• DNS{1,2}: 10.139.1.1, 10.139.1.2
• Subnet: 255.255.255.0
• IP: to find the VM's ip, run qvm-prefs vmname visible_ip in dom0. Caveat: a cloned/restored/... VM will likely have its IP changed so you'll have to remember to update your network settings.
• Gateway: to find the ip, run qvm-prefs vmname visible_gateway in dom0

Issue 2 - Copy/Move functions

• If the username you log on with in Windows is different than qvm-prefs vnname default_user (usually 'user'), then the 'QubesIncoming' folder is located in C:\Windows\System32\config\systemprofile\Documents\QubesIncoming\ (and launching .exe's directly from this folder sometimes fail, in which case one has to copy the .exe somewhere else (eg. on the desktop) and run it from the new location). Fix it with qvm-prefs vnname default_user winusername where winusername is the username you log on with in windows.

• In R4 the qvm-{copy,move} operations don't require the destination VM as argument: the destination VM is later typed by the user in a dom0 popup gui. When using R3.2 tools in R4 and copying/moving a file from/to a Windows VM, the user will be presented with a "destination VM" popup menu twice - once in the windows VM and once in dom0 (it is OK to leave the VM field blank in windows though).

Issue 3 - inter VM copy/paste doesn't work

Workaround: copy text in files and copy/move them accross VMs.

Issue 4 - creating Windows AppVMs based on a Windows TemplateVM

Problem: the private disk is present in the AppVM but QWT doesn't initialize it if it's empty (format + relocate user profiles). As a result user profiles aren't found at startup and the AppVM is stuck at "Preparing your desktop" for a 2-3 minutes until it timeouts. The vm is then barely usable because of the lack of user profiles.

Workaround (work in progress): copy the private disk of the TemplateVM to the AppVM - see this ML thread

Problem 2: Qubes doesn't copy a template VM's prefs when creating a VM so the new VM's prefs will be the "default" ones and won't be set properly for windows ; eg.

qvm-prefs winTemplate kernel -> ''
qvm-prefs winTemplate virt_mode -> 'hvm'
qvm-prefs winTemplate memory -> '2096'

qvm-create --template winTemplate --label red wintest
qvm-prefs wintest kernel -> '4.4.18-1'
qvm-prefs wintest virt_mode -> 'pvh'
qvm-prefs wintest memory -> '400'

Solution: set the preferences to match those of the templateVM.

Fixing QWT

See this message from Marek.

• Networking isn't set up properly: use /qubes-primary-dns ; looks trivial (
  https://github.com/QubesOS/qubes-core-agent-windows/blob/master/src/network-setup/qubes-network-setup.c)
• Copy/Move functions: fix the copy/move functions/gui not to require any argument (https://github.com/QubesOS/qubes-core-agent-windows/blob/master/core-agent-windows.wxs)

[dmoerner]

Thanks for this as well. These 3 issues aside, have you had success installing QWT in a fresh Windows 7 VM on Qubes 4rc4? I've been able to install QWT, but after shutting down the VM after the successful install, the VM never boots again. It either crashes on the initial black Windows loading screen, or tries to fix the problem and tells me it can't fix the problem. (I've now experienced this twice.)

The error I get is:

Problem Signature 01: 6.1.7600.16385
Problem Signature 02: 6.1.7600.16385
Problem Signature 03: unknown
Problem Signature 04: 21198045
Problem Signature 05: AutoFailover
Problem Signature 06: 2
Problem Signature 07: BadPatch
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033

[ghost]

These 3 issues aside, have you had success installing QWT in a fresh Windows 7 VM on Qubes 4rc4?
I installed on 4rc3 before the update to rc4 but there shouldn't be any difference.

I remember having a lot of crashes when I was trying to install Windows, which is what led me to write the instructions here and in #3592. Windows will try to fix the install (always unsuccessfully) when it detects that the previous startup crashed (that's why cloning after each successful installation step is important - once you get a crash you have to begin from scratch).
I didn't encounter any crash like yours (BTW, where do you get the error ? In one of Qubes' log files ?).
You may want to try the following (please comment if it helps so that I update the doc):

• have you followed QWT's README ? (IIRC you need to do something like bcdedit... in an admin command prompt to enable test signatures).
• make sure you don't install the storage PV driver if you select 'custom installation' in QWT
• Windows being Windows, try to reboot at least two times after a clean install before installing QWT.

[github74829]

I have had success installing the tools, thank you very much.

Would you be so kind and inform me how I can disable the Qubes Network Setup and setup the network manually? I have tried setting the Windows 7 IP address to the one shown in Qubes manager and the DNS/gateway to sys-net, but that does not work.

[awokd]

@github74829 From https://mail-archive.com/[email protected]/msg02800.html:

So you can simply disable the "Qubes Network Setup" service instead of renaming the .exe

[dmoerner]

After a third attempt to carefully shepherd the Windows updates, I was able to get the VM into a stable state and install QWT, seemingly without problems. (I did need to set qrexec_timeout 300 as the wiki suggested.)

@github74829: You can disable it in msconfig.

(For reference: The relevant error I found earlier can be found in "Startup Repair" when Windows fails to boot, rather than a Qubes log.)

[github74829]

I have renamed the .exe and did a restart but still no connectivity.
Here's my Windows network adapter setting for IP4 (IP6 is disabled):
IP 10.137.0.15 (as shown in Qube manager under networking)
Subnet 255.255.255.255
Standard Gateway 10.137.0.5 (sys-net)
DNS Servier 10.137.0.5 (sys-net)
What am I doing wrong?

[dmoerner]

@github74829
As mentioned in the mailing list post above, you need the DNS servers to be 10.139.1.1 and 10.139.1.2 (or something similar, just check /etc/resolv.conf in an arbitrary Linux VM).

[ghost]

@dmoerner : happy to read it worked. Do I understand correctly that you fully updated Windows before installing QWT ? I didn't run windows update in my VM - it always takes forever and my VM is network isolated so I simply disabled the service, but it will be nice to know so that I can update the doc. Also FWIW I didn't have to change the qrexec_timeout - maybe because my PC wasn't under heavy I/O when the VM was started.

@github74829 : I see a thumb up in the post above so I guess you managed to get networking up and running...

DNS servers: I was wondering whether their IPs were random or hardcoded when I posted to the ML; I now see they are hardcoded in /usr/lib/python3.5/site-packages/qubes/vm/mix/net.py in class "NetVMMixin" / def dns(). I'll update the doc with the IPs.

BTW this issue wasn't really meant to be a detailed guide like the instructions in #3495 but it looks like it would be helpful to people to have more detailed instructions. I'll try to update the doc tomorrow.

[dmoerner]

@taradiddles Yes, I fully updated Windows before installing QWT. I find it doesn't take too long at all since they bundled SP2 into a single download.

I find it helpful to increase qrexec_timeout because in case you happen to get a BSOD or a similar crash in the VM, chkdsk won't complete on restart before qrexec_timeout automatically halts the VM. That can really put the VM in a totally unrecoverable state, whereas with higher qrexec_timeout, chkdsk or the appropriate utility has plenty of time to fix the VM.

[github74829]

@taradiddles Yes I did, thank you very much.
Now I have to see what to do in order for Windows Update to run, it seems like it is stuck. I have already installed QWT, if they prevent Windows Update from functioning correctly, I might have to uninstall QWT, run the updates and re-install QWT again.

[dmoerner]

@github74829
If you're trying to get Windows Update to run on a fresh install of Windows 7 Pro SP1, you need to manually install some updates by following steps 1-11 in this guide: https://plugable.com/2016/06/08/windows-7-wont-update-what-to-do/. Even after doing this, you may find you have trouble installing particular updates and may have to restore the VM from a backup made with qvm-clone; in that case, manually downloading the update and installing it is generally the easiest thing to do.

If your Windows Update appears to be in some sort of a broken state (determined by running Microsoft's diagnostic, here's a direct link: https://aka.ms/diag_wu), then follow this guide: https://support.microsoft.com/en-us/help/971058/how-do-i-reset-windows-update-components. Note that not all of the dll's will exist on Windows 7; that's fine.

I don't think that QWT in itself is likely to cause any problems with updating.

[ghost]

Thank you both for the feedback, I've updated the docs accordingly.

I don't think that QWT in itself is likely to cause any problems with updating.

It doesn't seem to, but I found out that with QWT installed you don't see the "updates in process" (or whatever it's called) when the VM is being shutdowned. Large updates can take a while and you're left wondering what's happening (I killed the VM too hastily the first time and it broke Windows. The second time I didn't do anything and the VM stopped by itself after a few minutes; during that time xentop showed the VM's CPU varying).

[AJolly]

I was also unable to get QWT installed if I unchecked the option to move user profiles.

[hugoncosta]

I'd like to chip in with my experience. Created a win7 x64 ultimate SP1 vm. Followed the instructions on this issue + doc/windows-vm. Doing the extend with 25g will net only 1.36gb of open space with 0 installations on the ultimate edition, so I increased it post installation. It'll really depend on the user, but I'd change it to at least 30GB as a conservative estimate.

Everything worked perfectly, thanks! I did notice a difference compared to R3.2. I had the memory set at 2048 and a maxmem of 4096, which worked fine, but on R4.0 it'd consistently crash my 2 imported vms. I only thought it'd be a nice idea to try it after I erased them and started building the new one. This is already stressed on the tutorial, just a fyi.

[ghost]

@hugoncosta : thanks for the feedback. I'll try to submit a PR to the win7 doc with more info about minimal volume sizes.

@evadogstar

Any progress with fixing this issues for Q4?

Unfortunately no, it's a community effort and nobody with visual studio experience has stepped in to help (IIRC at least one user tried to set up a build environment but it didn't work). I personally know nothing about building stuff on windows and don't have the time/will to learn it. Most of the issues seem pretty straightforward to fix though.

[mossy-nw]

hi @taradiddles thank you for compiling this helpful advice! Could you please add to " QWT Installation Check the rpm's signature... " something like the following?

Please import the Qubes Release 3 Signing Key in the VM where you are confirming the rpm signature (otherwise you will get the error qubes-windows-tools-3.2.2-3.x86_64.rpm: digests SIGNATURES NOT OK). Get the key here and import it to your rpm keyring using:

sudo rpm --import qubes-release-3-signing-key.asc

It is also a good idea to check the key fingerprint as follows:

gpg2 --import qubes-release-3-signing-key.asc
gpg2 --fingerprint "Qubes OS Release 3"

The correct fingerprint (I hope!) is C522 61BE 0A82 3221 D94C A1D1 CB11 CA1D 03FA 5082

[ghost]

Thanks, I've added your comment to the doc.

Interestingly, IIRC rpm -K was working without having to import the signing key when I wrote the doc (back in 4.0 rc something). Maybe the key was removed by 4.0 updates; or maybe I imported it for some other purposes and forgot about it.

[Polygonbugs]

Thank you @taradiddles. I followed your tutorial QWT installation and finally made it successful. But after installing QWT, there is issue about two windows being opened in one Windows-OS VM. One seems to be freezed at Windows boot logo screen when booting is almost finished and the other one just normally show desktop of Windows-OS. Although OS is working well including shutdown of VM, could this be problematic (except visual experience)? I didn't yet test about seamless mode. Do anybody know how to set seamless mode? I can't see it on qvm-prefs command in R4.0.

[ghost]

two windows being opened in one Windows-OS VM. One seems to be freezed at Windows boot logo screen when booting is almost finished and the other one just normally show desktop of Windows-OS

That's likely because you didn't turn off the vm's debug property (run qvm-prefs <vmname> debug false)

[Polygonbugs]

That's likely because you didn't turn off the vm's debug property (run qvm-prefs debug false)

Oh! Thanks. I forgot to disable debug property. Now it works charm! BTW, I'm wondering that seamless mode is dead option in Qubes-R4. I've searched a lot but I couldn't see how to do. If it is dead in R4, I think it should also be contained in as new issue.

[marmarek]

@Polygonbugs the missing piece is a knob to switch it on/off. You can do it manually:

echo SEAMLESS | qvm-run -p --service VMNAME qubes.SetGuiMode

And to set it back to full desktop:

echo FULLSCREEN | qvm-run -p --service VMNAME qubes.SetGuiMode

[DemiMarie]

It goes in HKLM\Security\Policy\Secrets which by default even admins can't expand. Users have no access to the security key by default.

And even that is not really secure: There is a tool called Registrar Registry Manager which can expand it. The value is stored in HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\DefaultPassword\CurrVal\\(default), which yields for me a typeless 92 Byte value. So one can only hope that the encryption is strong enough, but anyhow, providing a possibility for decryption weakens the concept of just storing a hash value and never storing the password itself, encrypted or not.

It’s secure in the sense that Microsoft would issue a bulletin if an unprivileged user could retrieve it, with the possible exception of the user whose password it is. That’s good enough for me, but I agree that it is a poor design.

[marmarek]

https://openqa.qubes-os.org/tests/37272 - some preliminary automated tests of QWT. It uses @ElliotKillick qvm-create-windows-qube for setup, and then test:

• starting an app from the menu
• clipboard past into windows
• file copy out of windows
• network inside windows (by opening qubes website in MS Edge)

Adding more tests would be nice, but this already covers quite a lot of basics (like - whether the whole thing doesn't outright crash).

[DemiMarie]

• network inside windows (by opening qubes website in MS Edge)

This is only for Windows 10 and 11, right? Having a Windows 7 qube with any Internet connection at all is a bad idea.

[marmarek]

Having a Windows 7 qube with any Internet connection at all is a bad idea.

Whether that's a good or bad idea is irrelevant here. Network access from within Windows VM (or any other, for that matter) should work if user configures it as such. Side note: "working networking" does not necessary mean "internet access".

[Kenny606]

It goes in HKLM\Security\Policy\Secrets which by default even admins can't expand. Users have no access to the security key by default.

And even that is not really secure: There is a tool called Registrar Registry Manager which can expand it. The value is stored in HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\DefaultPassword\CurrVal\\(default), which yields for me a typeless 92 Byte value. So one can only hope that the encryption is strong enough, but anyhow, providing a possibility for decryption weakens the concept of just storing a hash value and never storing the password itself, encrypted or not.

It’s secure in the sense that Microsoft would issue a bulletin if an unprivileged user could retrieve it, with the possible exception of the user whose password it is. That’s good enough for me, but I agree that it is a poor design.

Yeah like I said it has its own vulnerabilities, but an improvement over the alternative.

These are the same people that added an option to purposely store passwords using reversible encryption somewhere around the Windows 2000 era as I recall.

Whatever there justification was 15 or 20 years ago ago for whatever systems may have been around at the time. I'm pretty sure that it should be gone by now at least in Windows and AD.... If a damn application or service can't function without that enabled in AD I won't be recommending it. The option still existing on a domain controller or workstation waiting for someone to abuse it is a major issue.

[GWeck]

This is only for Windows 10 and 11, right?

It works for W7, too.

Connecting a Windows qube to the internet is risky, but some threats can be mitigated by restricting possible connections to selected, hopefully harmless, sites via sys-firewall. Or just restricting it to the local network. Anyhow, if a Windows AppVM is compromised, most attacks will be made uselss on restart of the qube.

What is troubling me more, is that, especially for W10/11 with Office 365, periodic connection of the template to the Microsoft servers is necessary in order to reactivate the license. For that, I still have no solution.

[GWeck]

Adding more tests would be nice

See lalso [WIP] Windows/QWT user reports]. My reports on W7 and W11 cover also W10, which behaves exactly like W11.

[GWeck]

The remaining points are quite minor and can be tolerated well, until perhaps some of them may be fixed:
* Audio for Windows 7 does not work; for Windows 10 and 11 it works but sounds somewhat scratchy.
* For Windows 7 in non-seamless mode, screen resolution cannot be reasonably set.

Update on these points:

• Audio on Windows 7 does work, if the Windows Audio Endpoint Builder service is activated (set to start type "automatic") and the audio services are started (at least after the next VM boot), and the sound is clear and not scratchy like on Windows 10 or 11.
• The window size for Windows 7 in non-seamless mode can be changed using the Alt+F8 key combination.
• If, prior to QWT installation, the drive letter for the private volume on Windows 7 templates is changed from D: to Q:, the Move User Profiles option works for Windows 7, too.

I have updated my user reports accordingly.

[GWeck]

I just created a new issue Provide information on integrating Windows into Qubes R4.1 #7381pointing to 2 pull requests for instructions about installing a Windows qube and installing QWT 4.1.67, as well as on migrating Windows VMs from Qubes R4.0 to R4.1.

The instructions in these pull requests are just a first draft - any comments and improvements are highly welcome!

[Geblaat]

• network inside windows (by opening qubes website in MS Edge)

This is only for Windows 10 and 11, right? Having a Windows 7 qube with any Internet connection at all is a bad idea.

I still have a Windows 7 Qube with internet connection. Note that 7 still gets security updates until Jan 2023 IF you get ESU.

[Szewcson]

What is the current status? QWT is on testing for a few months now, when it can be moved to stable repo?

[andrewdavidwong]

This issue appears to be outdated and overly broad.

[github-actions]

This issue has been closed as "not applicable." Here are some common examples of cases in which issues are closed as not applicable:

• Help and support requests (please see Help, support, mailing lists, and forum)
• Questions (please see Help, support, mailing lists, and forum)
• Discussion issues (please see Help, support, mailing lists, and forum)
• Bug reports for behavior that is already working as intended
• Enhancement requests to improve things that are already working as intended
• Issues that rest on mistaken assumptions or misunderstandings
• Issues that do not provide enough information
• Issues that are not actionable

We respect the time and effort you have taken to file this issue, and we understand that this outcome may be unsatisfying. Please accept our sincere apologies and know that we greatly value your participation and membership in the Qubes community.

Regarding help and support requests, please note that this issue tracker (qubes-issues) is not intended to serve as a help desk or tech support center. Instead, we've set up other venues where you can ask for help and support, ask questions, and have discussions. By contrast, the issue tracker is more of a technical tool intended to support our developers in their work. We thank you for your understanding.

If anyone reading this believes that this issue was closed in error or that the resolution of "not applicable" is not accurate, please leave a comment below saying so, and we will review this issue again. For more information, see How issues get closed.

[andrewdavidwong]

Also appears to be a duplicate of #1861.

[github-actions]

This issue has been closed as a "duplicate." This means that another issue exists that is very similar to or subsumes this one. If any useful information on this issue is not already present on the other issue, please add it in a comment on the other issue. Here are some common cases of duplicate issues:

• The other issue is closed. The other issue being closed does not prevent this issue from duplicating it. We will examine the closed issue and, if appropriate, reopen it.
• The other issue is for a different Qubes release. We usually maintain only one issue for all affected Qubes releases.
• The other issue is very old. The mere age of an issue is not, by itself, a relevant factor when determining duplicates.

By default, the newer issue will be closed in favor of the older issue. However, we make exceptions when we determine that it would be significantly more useful to keep the newer issue open instead of the older one.

We respect the time and effort you have taken to file this issue, and we understand that this outcome may be unsatisfying. Please accept our sincere apologies and know that we greatly value your participation and membership in the Qubes community.

If anyone reading this believes that this issue was closed in error or that the resolution of "duplicate" is not accurate, please leave a comment below saying so, and we will review this issue again. For more information, see How issues get closed.