GRUB will never overwrite anything on the EFI system partition and certainly not the Microsoft folder.
The ESP must have been formatted at some stage.
Does the ArchLabs installer keep a log? (I’ve never used it.)
EDIT: you should be backing up the contents of the ESP anyway, then you wouldn’t have to keep reinstalling.
Create an additional EFI partition the usual way and instead of selecting the EFI partition created by Windows, use this one. After installing run the usual grub command to write its config, windows should be found at this point.
The installer can be run with -d/--debug to have pretty much everything logged to /tmp/debug-log by default output of stderr is logged to /tmp/errlog
If there is a Microsoft folder present on the partition then its obvious it was never formatted. To the best of my knowledge windows doesn’t even store the actual bootloader on the partition though this may have changed.
It is likely that this is being overwritten.
To stop this from happening open the installer located at /installer/installer navigate to line 1946 and comment the line containing grub_uefi_fallback
Ah yes, of course, I missed that bit.
The Windows UEFI loader is stored on the ESP at EFI/Microsoft/Boot/bootmgfw.efi
This is confusing to me. In theory I agree with what you say, @anon42040838, but how is it that OP and me both had the same issue - which is a missing bootmgfw.efi without actually formatting the efi partition? If what you say is correct and grub never overwrites anything… then… how?
My mistake, I could’ve sworn I’ve read it somewhere but probably just got some wires crossed
From what I can gather it seems that Windows is using EFI/Boot/bootx64.efi as a catch all of sorts, this wasn’t the case before and I may still be wrong.
During install this file is being overwritten with grub’s efi stub (by us), without it many computers will simply say “No bootable device”. I’ve outlined a solution in a previous post above.
Will get this fixed, but need to find a decent solution first.
Yes that is correct @natemaia EFI/Boot/bootx64.efi in most cases. But on some machines it may have a different directory setup:
G:\EFI\Microsoft\Boot
G:\Boot\ or
G:\ESD\Windows\EFI\Microsoft\Boot`
Mine happens to be G:\EFI\Microsoft\Boot\
This is something I am hoping that will give @MuradTroll would look at to help him:
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=2ahUKEwipmezf5e3cAhVQ71QKHaijAfUQFjACegQIBhAK&url=http%3A%2F%2Ftech.memoryimprintstudio.com%2Fdual-boot-installation-of-arch-linux-with-preinstalled-windows-10-with-encryption%2F&usg=AOvVaw1CngRvDVCEsslrAG19hfP-
Ok good to know that about the boot setup
The link is a dead redirect
Redirect Notice
The page you were on is trying to send you to an invalid URL.
If you do not want to visit that page, you can return to the previous page.
To shorten links using markdown the format is
[Label](Link)
eg. [Google](http://google.com)
How it looks outside of a code block: Google
This way people can just click the highlighted text rather than needing to copy/paste massive links 
Finally the message restriction is gone. I would like to thank you al for helping me out and giving active support. Furthermore I would like to announce, that I managed to solve the problem. In this post, I will deeply explain what I did and tried to fix it. I did try to install archlabs yet again, and in the live environment I did the following things
_EFI
__Microsoft
___Boot
___Recovery
__Boot
#[[ $SYS == “UEFI” && $BOOTLOADER == “grub” ]] && grub_uefi_fallback
Then I ran the installer and everything went fine, up to the point where grub was installed, I noticed my filemanager refreshed immediately and the bootloader was gone. But then I realized something very important: the new files structure was specific
_EFI
__Microsoft
___Recovery
__archlabs
When you comapre that with the filestructure before, you will realize that 2 folders are missing, specifically those called Boot. Because I inspected the installer script beforehand, I immediately knew what the problem was. This line:
find $MNT/boot/efi/EFI/ -name '[Bb][oO][oO][tT]' \
-type d -exec rm -rf '{}' \; 2>/dev/null
is actively deleting all folders in the partition called ‘Boot’ (and with all I mean all, even in the Microsoft folder). Now I installed Windows yet again, booted into arch-live again, commented both lines out (this one and the one that calls grub_uefi_fallback()) and ran the installer again. No bootloader was deleted, and I had both OSes ready to run.
So in the end all of us were right, neither I, nor GRUB were deleting any of the entries in the EFI partition, but archlabs installer was.
The problem is that this command is trying to delete preexisting (old) boot entries in the EFI partition (probably created by older versions of archlabs), but with ‘find’, it does a full search for a directory called ‘Boot’ in all subdirectories (-> it touched the Microsoft folder). I don’t know if the first ‘Boot’ folder (the one that is not in the Microsoft folder) can be touched/deleted. But for sure, the Microsoft folder (and specifically the Boot folder inside it) should NOT be touched at all. I would suggest adding something like
-mindepth 1 -maxdepth 1
to prevent this from happening in future installs.
At this point I am also not sure if commenting out the grub_uefi_fallback() was really necessary, but it seems like this function is trying to delete some files too, so I commented it out just to be sure.
At the end I want to thank you all yet again and point out, that this is literally my
and it was really a valuable experience.
@MuradTroll , thx for the great explanations there mate , will be great for other future uses.
@MuradTroll Great stuff.
Big mistake there on my part not using a -maxdepth 1 flag with the find, very dense of me to miss this as a probable cause so I apologize.
Cheers
Top notch sir.
I actually wanna thank you and say I’m thoroughly impressed with the excellent breakdown, understanding of Unix cli tools, and willingness to get you hands dirty understanding the installer.
More often than not people are unwilling to help themselves (whether right or not) so this was a breath of fresh air.
Cheers
Excellent, and hopefully solved for others with the same issue. 
One thing that still bugs me, just out of sheer curiosity, is it valid if the first ‘Boot’ folder gets deleted (obviously not the one inside the Microsoft folder, but the one next to it)? Or will this likely cause the same problem? Same thing for grub_uefi_fallback(): will it break if called during install? Many questions still unanswered but for now I think I have experimented enough 
Really depends on your bios and motherboard manufacturer whether having a generic EFI/Boot/Bootx64.efi is really needed. The problem was indeed the boot folder within Microsoft’s efi folder being deleted, I don’t think the others will cause any issues.
It would also depend on which OS’s bootloader you want as the dominant
I would not mess with any folders in your EFI partition ie. your boot folders unless you know what you’re doing. But I would suggest that you make a copy of that partition and save somewhere safe in case you have problems with your installations and you wouldn’t have to keep reinstalling your OSs again and again and again…
Just as a sidenote: you do NOT have to do that, recovery medium and one simple command is enough to restore win bootloader. Not a single reinstall neccessary.
That being said, @MuradTroll, congratulations on actually solving the issue!
That’s true, but it doesn’t work for the linux side. But, still a good call. Pease
Sorry @xsme, somehow I edited your post event hough I had hit reply. but my reply was:
That’s true, but it doesn’t work for the linux side. But, still a good call. Pease
I’ll let you fix your post, don’t want to try and mess it up more.
Thanks man i’ll give it a try for this solution … since my problem quite the same as yours.
*Updated
Confirmed its worked on me too. Latest iso ( 2018.07.28 ) on my asus laptop with uefi system, dual boot with windows 10.
Before that i desperately frustated with this grub2 problem. I even had to reinstall windows twice along with archlabs.
And in my case, after successfull archlabs setup ( of course with those tricks you have been wrote ) i had to reboot but still no windows on grub so i enter newly created archlabs then manualy ran os-prober and grub-mkconfig. I was trully happy with the end result, grub finally see my windows efi partition.
Excelent job … Very much appreciated 