I have dual OS installed one linux manjaro and windows 10 and it uses grub v2.02 bootloader.
It shows windows 10 in the list to boot but when selected it goes to a dark screen with text saying cannot detect any OS on device. Make sure to unplug
any device that's connected that has no OS then says press control alt delete to restart.
It sounds like you are using a legacy BIOS system. "This is not a bootable device" and "An operating system wasn't found" are bootsector messages before BootMGR loads, and only legacy BIOS uses bootsectors. The BIOS firmware reads the first 434 bytes of the disk, which is the Master Boot Record. The Master Boot Record code is for interpreting partitions, so it reads the MBR partitioning tables from the end of the same first sector with the boot code. Master Boot Record code is not always the same, but in the case of Microsoft Windows MBR code, which is present on even empty pen drives formatted in Windows and some Linux disks previously formatted with Windows (unless the Linux installer replaced the MBR), the MBR finds the partition set as Active, and loads the Volume Boot Record from the filesystem header at the beginning of the active partition. BIOS reads disks to run MBR, MBR reads partitions to run VBR, and VBR reads filesystems to load BootMGR, GRUB, or something else in the active partition. If GRUB is loaded first, it can then load BootMGR by the file or through VBR sectors. Once Windows Boot Manager is loaded (in B:\Boot\bootmgr on legacy systems), it uses the Boot Configuration Data (in B:\Boot\BCD on legacy systems) to load Windows (in C:\Windows\System32\winload.exe on legacy systems).
If it's a BIOS only system and Windows is supposed to be BIOS+MBR, the Master Boot Record directs to GRUB (whether it was written by GRUB or Windows), but that's not the issue as GRUB's option to Windows doesn't route through the MBR unless it's a different disk, or it would loop back to GRUB. As the Windows option in GRUB displays small black text, that means it's using the VBR in the beginning of the Windows Boot Manager partition instead of directly starting the BootMGR file, but the Volume Boot Record in the Windows Boot Manager partition is written by Windows and wasn't overwritten by GRUB, or else it wouldn't display this error text. What's possible is the Linux installer moved the Active designation from the Windows Boot Manager partition to a GRUB partition. Although the active designation is used by the MBR to find the correct VBR, it's possible the VBR checks the partition it is in, in the same way the MBR checks if the disk it's in is considered bootable by the switch in the partition table. Only 1 partition can be set as Active, at least when the MBR conforms to the standards of Microsoft Windows MBR boot code.
Was Linux installed in BIOS+GPT mode alongside Windows? If so, BIOS+GPT boots in legacy BIOS mode of course, and while GRUB can support BIOS+GPT, all GPT Windows installations are UEFI+GPT. If the Linux installer booted BIOS+GPT and is trying to load the Windows UEFI+GPT installer, GRUB will be trying to load the Volume Boot Record of the Windows Boot Manager partition, which will not work for a FAT32 formatted EFI partition. Linux may have been installed in legacy BIOS mode if the installer USB was booted in legacy BIOS mode, and then installed BIOS+GPT. Your firmware may have booted UEFI mode when only Windows was installed, but switched to Legacy BIOS mode if GRUB added boot code to the Protective MBR. If the firmware automatically switches between full UEFI and legacy BIOS CSM mode, instead of providing a choice, this possibility isn't off the table. If your computer is strictly limited to BIOS only, then it's not this.
If Windows is installed in UEFI+GPT mode, Windows Boot Manager exists in B:\EFI\Microsoft\Boot\bootmgfw.efi and can be directly loaded from the firmware without GRUB by setting "Windows Boot Manager" as the 1st in the boot priority list, and switching boot mode to UEFI if it's not automatic. If this isn't possible, the HDD model option uses B:\EFI\Boot\bootx64.efi. That file, like Master Boot Records, can only be used by one bootloader and may be required by GRUB, but if you are willing to possibly leave GRUB unbootable, you can use that to directly load Windows Boot Manager by copying B:\EFI\Microsoft\Boot\bootmgfw.efi to replace B:\EFI\Boot\bootx64.efi and setting HDD model as 1st.
If Linux is installed in BIOS+GPT mode, Windows may be bootable by setting the boot mode to UEFI only, disabling the ability to boot in legacy BIOS mode. If there's no firmware option for UEFI only, enabling Secure Boot does it. Either way, a BIOS+GPT Linux would become unbootable, so it's better to try moving Windows Boot Manager higher priority so it can be booted directly, and as such, so the firmware can detect it ultimately requires UEFI mode instead of being pulled into using Legacy mode by starting with a BIOS+GPT GRUB.
It could simply be the BootMGR files are missing and can't be located by the Volume Boot Record of the Windows Boot Manager partition. If Linux used the same partition for GRUB files, that's possible. The bcdboot command in Windows adds Windows Boot Manager files to a partition, though that will overwrite existing boot files with matching names. Since bcdboot creates defective Boot Configuration Data preventing the Windows Recovery Environment from working, the BCD from bcdboot shouldn't be used, only the other Windows Boot Manager files, while the existing BCD can be renamed so it isn't overwritten, and then renamed back.
There is too much speculation to perform, and continuing without knowing more about your disks would be excessive risk to jump into. 1)
Open GNOME Disks and capture a screenshot of your disk partitions. 2)
Open Terminal and use
sudo gdisk /dev/sda
and press Enter. 3)
(as in Print) and press Enter. 4)
(as in Verify) and press Enter. 5)
(as in Quit) and press Enter 6)
Screenshot the Terminal as well, and upload both screenshots.