I just now started having this problem. I've been playing apex since launch. I scanned my system with my AV and removed all threats. I put EAC as an exemption. I uninstalled and reinstalled the game. I tried repairing it also. My OS is legit and active. What else is there to do?
[Info] Desktop screen settings detected. DPI: 96 DPI Multiplier: 1.000000 BPP: 32.
[Info] Localization loaded for: 'en-US'.
[Info] Settings file full path: 'D:\Program Files (x86)\Origin Games\Apex\EasyAntiCheat\Launcher\Settings.json'.
[Info] Start. ExecutablePath: 'D:\Program Files (x86)\Origin Games\Apex\R5Apex.exe' LaunchParameters: '-eac_executablename "R5Apex.exe"' WorkingDirectory: ''.
[Info] Finished window initialization.
[Info] [LauncherFinished] EACAsyncResult: 4 Message: 'Patched Windows boot loader detected (0xC0010002)'.
[Info] Exit button pressed by user.
[Info] Unloading the EasyAntiCheat library.
[Info] Destroying windows.
[Info] Exit.
If you have a modern computer where Windows 7 Setup halts at boot time when displaying OS logo, then you need to apply the patch for Windows 7 UEFI loader in FlashBoot Pro. This patch provides emulation of VGA BIOS (INT 10H) over UEFI GOP framebuffer, thus enabling installation and use of Windows 7 on the modern purely UEFI-based computers without CSM.
And if you have a dual-boot configuration of Windows 10/11 and Windows 7, you need to have two UEFI loaders simultaneously: a new one, capable of booting Windows 10/11 (with modern features, frequently updated by Windows Update); and older one, dedicated for booting Windows 7, patched by FlashBoot Pro for VGA BIOS emulation (thus, Windows Update preferrably should leave it alone).
Please be aware that in dual-boot configurations of Windows 10/11 and Windows 7, CheckDisk may kick in on every reboot of Windows 7. This is totally unrelated to the aforementioned UEFI boot shenanigans, and happens on CSM/Legacy systems too. Why it happens and what can be done about it, please read in the separate article (in short: a small registry tweak in Windows 10/11 is necessary to make it use old format of NTFS log compatible with Windows 7 and its CheckDisk).
A: Most convenient way is to use Emergency Boot Kit, see User Guide for Partition Manager: pages 36, 37, 39 and 40 demonstate this process step-by-step. If you do not have a paid version of Emergency Boot Kit, you can do this for free in a live Linux distribution like SLAX: run lsblk command to list all block devices, then run fdisk -l /dev/sda, fdisk -l /dev/sdb, fdisk -l /dev/mmcblk1 etc (substitute your block device name after /dev as necessary) to determine which Linux block device is your main internal bootable storage device, then run fdisk -l /dev/(chosen_device_name) to start editing partition table, then p subcommand to print partition table, thent subcommand to change partitition type, then 1 for "EFI system" type or 11 for "basic data" type, then w subcommand to write altered partition table to the disk. Alternatively, q subcommand exits fdisk program without saving altered partition table to the disk.
A: Most convenient way is via the UEFI firmware setup utility, but that depends on UEFI firmware vendor (consult user manual for your motherboard or laptop). Also there is a vendor-neutral method of changing UEFI boot order: using efibootmgr tool in live Linux distribution like SLAX. When run without parameters, efibootmgr displays current boot order (list of comma-separated numbers) and a table below (which explains a meaning of each number: for example, an OS name, or PXE network boot device name, or rEFInd boot loader name or whatever). Then you can run efibootmgr --bootorder XXXX,YYYY,ZZZZ,... with reordered list of the same comma-separated numbers. In such way boot order will be changed by efibootmgr and written into the UEFI configuration variables in the NVRAM.
I tried them, PatchFor4GB adds a boot option to the bootloader list, which is supposed to be the kernel-patched one, but everytime I boot with it, I only get a blank screen on my computer after the Windows logo splash and then it gets stuck there.
Because I use with my computer some hardware that uses privative drivers made ONLY for 32bit systems, I CANNOT INSTALL THE 64-BIT VERSION OF WINDOWS (they're a bit old, trust me, they don't work in Windows 64-bit). Please eliminate that as a possible answer. Sorry.
Do you know any reliable way to make my Windows 7 Ultimate able to use the total of the RAM my computer has installed? Any graphic or command-line solution is more than welcome and appreciated :D
No, there is no reliable patch though you could always upgrade to an nvidia/ati graphics card. In fact, poorly written drivers are the reason that Microsoft disabled access to memory above 4GB on 32 bit consumer OSes in the first place.
I also had such a problem. But tried the method posted here to the thread (thanks to the author). I tried uninstalling the HD graphics driver. The desktop settings were reset and the generic driver was automatically installed.Then I installed PAE and rebooted my computer. The computer booted up without a black screen. After that, I downloaded the appropriate HD driver and it installed. After the reboot everything worked.
I had an identical problem (using the PatchPAE patch) to the one stated such that whenever the machine was booted, I also got Win logo and then also a blank, black screen, and then nothing. Moreover, this happened on two machines. I was able to restart with the original unpatched kernel and all worked well. It was not that the patch was not working but there was some kind of compatibility issue related to NVIDA display card. This is a known problem. I discovered this on wj32.org discussion of the PachPAE patch. I changed to ATI and bingo! It worked like a charm.
In Use Bootrec.exe in the Windows RE to troubleshoot startup issues (applies to Windows 7 and Windows Vista) they say to use Bootrec.exe with options /FixMbr /FixBoot, but when I type "bootrec.exe /FixMbr" in a command prompt, Windows says:
Alternatively you can use "Dual-boot Repair Tool" which has a graphical interface to bcdboot.exe, bootsect.exe and other useful functions like boot sector view and ... one click dual-boot repair function for Windows 10/8/7/Vista (also can fix Windows XP boot files).
The other answers given here work great on MBR/BIOS systems, however if you're on a UEFI system like I am, bootsect will just write a semi-functional boot MBR over the GPT protective MBR and bootrec just gives an "Access denied" error message, and neither one has a functional option to fix a broken EFI system partition, which on a UEFI/GPT drive is what contains the bootloader that used to be stored in the MBR. There's unfortunately almost no up-to-date guides on fixing the UEFI Windows Boot Manager (almost all of them just say to run the graphical Startup Repair utility, but that doesn't fix the problem in all cases), but I finally found the correct solution buried in this article, which requires the use of the bcdboot command instead:
Now do select volume x (where x is the volume number for the ESP) and then assign letter=N: to mount the partition. Run list volume again and note that the ESP is now assigned a driver letter. Run exit to leave diskpart.
(Optional) If you are not currently dual booting and want to fully clean the ESP before writing a new bootloader, run format N: /FS:FAT32 to reformat it as FAT32. This is probably not necessary under normal circumstances, however, as bcdboot seems to do a good job of cleaning things up itself. Especially do not do this if you have a Linux distro on another partition or else you'll have to reinstall GRUB as well once you're done with this. Also note that the following steps should not affect an EFI GRUB install as long as you do not otherwise delete GRUB's existing directory on the ESP.
Finally, write the new bootloader to the partition with bcdboot C:\windows /s N: /f UEFI. This command rebuilds a new UEFI-compatible bootloader on the ESP mounted at N: using the Windows installation mounted at C:\windows. Once it's done, you can verify the new bootloader was written by running dir N:\EFI, where you should see a Microsoft directory containing the new Windows Boot Manager as well as a boot directory containing the fallback bootloader (along with other directories for any other bootloaders you have installed, such as GRUB for Linux).
Symptom: Had a Windows 10 blue error screen directly after choosing Windows 10 in the grub boot menu with some cryptic error code, which shows not much information. It says I should press F8 for troubleshooting or Enter to retry, but F8 just shows the same error.
Notes:The problem other solutions tries have when you have a working grub you may not want to break that. As such, e.g. do not overwrite the MBR (breaks MBR and requires grub reinstall then) or overwrite the boot sector.
I have been working with a user here who had a functional fedora install, then did an install (or reinstall) of windows 11. His ending situation was that the efi partition was recreated by windows and all fedora config of grub within the ESP was wiped out.
Working with the user I have been able to do a full recovery (almost). We have been able to use the live usb and do a full install of grub to restore the /boot/efi/EFI/fedora directory and files as well as recreating a new /boot/grub2/grub.cfg file. All his files in /, /home, and /boot were unaffected.
I have never had to make a boot loader functional from scratch previously, so would appreciate any assistance in the steps involved to make the link between grub being installed and the boot loader being accessible from bios to boot grub.
Doing further research I wonder. Would the grub-install command be the one needed? Possibly grub-install --target=x86_64-efi --efi-directory=/boot/efi /dev/nvme0n1 when the system is fully mounted and active in a chroot environment? His system is installed on nvme0n1 with the ESP on /dev/nvme0n1p1.
7fc3f7cf58