Showing results for 
Search instead for 
Did you mean: 

Critical error AESMService: SGX is Disabled at AESM Service startup

I have updated Windows for the latest version 1709 (17763.1). After the first run, I saw a critical error in the Event Viewer. In Services, AESMService is shown as running.
Please see attached screens.
My mainboard: MSI B250M MORTAR, CPU: Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz, VGA: NVIDIA GeForce 1050 Ti.
I was trying to reinstall the drivers Intel Chipset Driver,  Intel Management Engine Driver, Intel Software Guard Extensions,  but the error still persists.
Can you please help me? Thank you.

0 Kudos
7 Replies

Hi Jan.

Both your CPU and your motherboard support SGX (per the MSI web site), so it appears you have not enabled SGX in the BIOS yet.  First, make sure you have the latest BIOS installed for your motherboard ( and then see the manual for how to enable SGX (




I have the latest version of BIOS.
My BIOS setup is: SW Guard Extensions (SGX): Software Control. I was trying to set it enabled and when saving a BIOS setting, two settings are changed: "SW Guard Extensions (SGX): [Software Controlled] -> [Enabled] PRMRR Size: [INVALID PRMRR]->[128MB]" and Windows will start to blue screen "Stop code: MEMORY1 INITIALIZATION FAILED".
A week ago, I had a problem with the Intel Software Guard Extensions for I solved it with a clean installation of Windows. The problem with a critical error appeared after updating Windows to version October 2018 Update 1709 (17763.1).



Here is what I understand is going on, can you please confirm:

1) When SGX is set in BIOS to "SW Controlled", then you get the two screenshots you attached in the first post.

If so, this is expected. You will need to use an SGX App that requests the service to enable SGX, then reboot. When the systems reboots, BIOS will enable SGX.

Or, you can reboot into BIOS and set it to enabled.

2) If you choose to enable it yourself in BIOS, then Windows 1809 will bluescreen (please confirm as you said Oct 2018 1709, but it should be 1809, right?)

I have not seen reports of bluescreens for 1809, but it's possible something changed in the OS that would cause this.

When you said you solved it with a clean installation of Windows, which version of Windows10 were you installing? 1803? 1709?

After you saw the bluescreen, were you able to save the crashdump?

Did you build your PC yourself or is it from an OEM?




1. A week ago I made a clean installation of Windows 1803. With Intel Software Guard Extensions for everything was ok. SGX in BIOS has been set to Software Controlled.
2. Yes, when I choose the BIOS setting to Enabled, Windows boots to BSOD. It's the same with Windows 1803 or 1809.
Crashdump file probably did not save anywhere, because the computer was cyclically restarted until I changed the BIOS setup.
I built my computer myself.
When saving a BIOS setting, two settings are changed: "SW Guard Extensions (SGX): [Software Controlled] -> [Enabled]" and "PRMRR Size: [INVALID PRMRR]->[128MB]".



I believe what you are describing is an issue with BIOS or the OS.

The process to root-cause the issue is not the simplest, but you should be able to:

1) Disable SGX in the BIOS

2) Clean OS install, do not install any of the SGX SW

3) Reboot + Enable SGX

4) Boot Windows and observe that it crashes with BSOD

5) Go into BIOS and set SGX to DISABLED. Windows should boot now that SGX is disabled.

5) Boot Windows and obtain the crash dump , by default stored in:


( this location is controlled by the settings in  Control Panel > System and Security > System. Click Advanced system settings. Under Startup and Recovery, click Settings ( )

If you are able to obtain the crash dump, depending on the size, can you post it here?

Other alternatives are checking your system vendor to see if they have a BIOS update for your motherboard that you can apply.





I did everything you wrote, but the dump file was not created.
Interesting is that the computer will boot normally with SGX Enabled from the installation DVD of Windows 7 and Windows 10 older version.


It's hard to diagnose further without crash dump / live kernel debugger, I am not sure why the system isn't writing a crash dump.

I'll ask around to see if anyone has anyone has thoughts on why the system isn't able to write a crash dump.