locked
EMET 5.5 - EMET_GUI.exe crashes RRS feed

  • Question

  • Hi!

    I have just started testing EMET 5.5 for deployment in our AD environment. 

    I am experiencing some issues with EMET_GUI.EXE on some of my users machines.
    When users try to launch EMET_GUI from the taskbar it crashes with the following message:

    EMET_GUI has stopped working

    A problem caused the program to stop working correctly.
    Please close the program.

    The following has been taken from the EventLog:

    EventID: 1000
    Faulting application name: EMET_GUI.exe, version: 5.5.5871.31892, time stamp: 0x56aac3a8
    Faulting module name: KERNELBASE.dll, version: 10.0.10240.16683, time stamp: 0x56ad97a2
    Exception code: 0xe0434352
    Fault offset: 0x000000000002a1c8
    Faulting process id: 0x2270
    Faulting application start time: 0x01d163f323e05ece
    Faulting application path: C:\Program Files (x86)\EMET 5.5\EMET_GUI.exe
    Faulting module path: C:\WINDOWS\system32\KERNELBASE.dll
    Report Id: <Removed>
    Faulting package full name:
    Faulting package-relative application ID:
    EventID: 1026
    Application: EMET_GUI.exe
    Framework Version: v4.0.30319
    Description: The process was terminated due to an unhandled exception.
    Exception Info: System.Exception
    Stack:
    at HelperLib.Config.GetStringValue(System.String, System.String, Boolean)
    at GraphicalApp.MainForm..ctor()
    at GraphicalApp.Program.RunEmetGUI()
    at GraphicalApp.Program.Main(System.String[])

    The EventLog data above is taken from a Windows 10 client, however the behaviour is the same on Windows 7 clients.
    These are clients where EMET hasn't previously been installed. On other clients where earlier versions of EMET has been installed (5.2), the GUI works correctly. I have tested this on both a Windows 7 and a Windows 8.1 machine.

    EMET is installed on the client machines using IBM BigFix, where the installer MSI is fetched, and installed using "msiexec /i <file> /qn /norestart", as proposed in the EMET 5.5 documentation.

    Settings are delivered to the clients using group policy, using the adml and admx files provided by the EMET 5.5 installer.
    I have tried with different combinations in the GPO settings, including setting all to "Not configured". It does not seem to make any difference.

    Any help would be greatly appreciated! :-)

    And also, thanks to the EMET team for providing this neat product!

    Best regards.

    Wednesday, February 10, 2016 2:03 PM

Answers

  • Same issue here.

    I solved the issue by opening regedit as the admin user that will launch the GUI and created HKEY_CURRENT_USER\Software\Microsoft\EMET

    Once the entry added, the GUI was no longer crashing.

    • Proposed as answer by mktl Tuesday, February 16, 2016 4:08 PM
    • Marked as answer by Neguahpm Wednesday, February 17, 2016 9:34 AM
    Tuesday, February 16, 2016 2:14 PM

All replies

  • Same here and seeing crashes in my AD environment. Crashes on Win7 machines. Opens fine on my Win10.
    Thursday, February 11, 2016 2:58 PM
  • Are you seeing the same errors in the EventLog?

    Thursday, February 11, 2016 3:15 PM
  • Deployed 5.5 With SCCM 2012 - MSI installation with "msiexec /i "EMET Setup 5.5.msi" /qn /norestart"

    Identical crash and eventlog on all non local admin users  - GUI askes for elevated rights.

    Best regards.

    • Proposed as answer by IRQ Monday, February 15, 2016 9:24 AM
    • Unproposed as answer by IRQ Monday, February 15, 2016 9:24 AM
    Friday, February 12, 2016 1:15 PM
  • We're seeing the exact same issue on non-local admins; it prompts for credentials for non-admins, then bombs out afterwards. If the local user has admin rights, it opens correctly.
    Friday, February 12, 2016 3:12 PM
  • Deployed 5.5 With SCCM 2012 - MSI installation with "msiexec /i "EMET Setup 5.5.msi" /qn /norestart"

    Identical crash and eventlog on all non local admin users  - GUI askes for elevated rights.

    Best regards.

    Found something:

    EMET_Conf.exe -list_system
    EMET configuration for System mitigations (Registry) is:
    DEP: Application Opt In
    SEHOP: Application Opt In
    ASLR: Application Opt In
    Pinning: Enabled

    EMET configuration for Global Application mitigations (Registry) is:
    DeepHooks: False
    AntiDetours: False
    BannedFunctions: False
    ExploitAction: StopProgram

    If I install the application manualy it changes the Global Application Mitigation:

    EMET configuration for Global Application mitigations (Registry) is:
    DeepHooks: True
    AntiDetours: True
    BannedFunctions: True
    ExploitAction: StopProgram

    And soudenly the GUI is working - still askes for elevated rights.

    Monday, February 15, 2016 9:33 AM
  • Same issue here.

    I solved the issue by opening regedit as the admin user that will launch the GUI and created HKEY_CURRENT_USER\Software\Microsoft\EMET

    Once the entry added, the GUI was no longer crashing.

    • Proposed as answer by mktl Tuesday, February 16, 2016 4:08 PM
    • Marked as answer by Neguahpm Wednesday, February 17, 2016 9:34 AM
    Tuesday, February 16, 2016 2:14 PM
  • I have the same problem. Someone tell me how to solve it?

    I tried to install Emet locally on a PC and remotely through Kaspersky Security Center.

    Thanks!

    Tuesday, February 16, 2016 2:19 PM
  • These are clients where EMET hasn't previously been installed. On other clients where earlier versions of EMET has been installed (5.2), the GUI works correctly. I have tested this on both a Windows 7 and a Windows 8.1 machine.

    I tested Emet 5.5 Beta - also works fine on Windows 7.
    Last version Emet 5.5 depending on the service Secondary Logon, maybe this is the reason?
    Tuesday, February 16, 2016 4:19 PM
  • Same issue here.

    I solved the issue by opening regedit as the admin user that will launch the GUI and created HKEY_CURRENT_USER\Software\Microsoft\EMET

    Once the entry added, the GUI was no longer crashing.

    it helped - Emet Gui works. But now there is a message "DEP/ASLR policy settings ineffective by default; see user's guide for how to enable them". In previous versions, this was not. This innovation of this version Emet?
    • Edited by dahiko Wednesday, February 17, 2016 3:01 AM
    Wednesday, February 17, 2016 3:00 AM
  • Hi,

    creating the key seem to solve the problem. Thank you very much for the information! :-)

    As a little experienced Windows admin, it would be very helpful to know how you were able to pinpoint the issue. Would you mind sharing how you approached this?

    Best regards 

    Wednesday, February 17, 2016 9:41 AM
  • Hi,

    What made me think of this was the post before mine: issue with the GUI when installed via SCCM and no issue when installed locally. As the install user is different, I compared the EMET HKCU settings and only noticed that the EMET key was not there. Gave it a try and GUI worked fine ;-)

    That being said, I now also have the DEP/ASLR policy issue.

    Wednesday, February 17, 2016 10:20 AM
  • You can also use Procmon as you start the gui and compare the logs between the working and nonworking. It may look scary with so many entries, but it's doable.
    Wednesday, February 17, 2016 1:39 PM
  • Wow I JUST came on here to post this exact same issue.  I was diagnosing an issue with someone and their phone system software freezing when responding to an interaction (handles both voice and email interactions for a call center).  Issue is sometimes those email interactions (involve the outlook and word process) hang the client.  Wanted to see if EMET was the culpret so I went on the users machine to check what protections are loaded and verify it was receiving our group policy properly.  Of course the user is not an admin but thats ok becasue opening the guy prompts for credentials.  I enter my admin credentials and immediately it "stopped working" and in the event viewer is that same issue 

    EMET_GUI.exe 5.5.5871.31892 faulting module KERNELBASE.dll version 6.1.7601.19110, Exception Code: 0xe0434352,  I thought there was something to do with .net but I checked windows update and none were available.

    Windows 7 Pro machine.

    I run Windows 10 Pro and it opens fine.

    We had EMET 5.2 deployed via group policy and recently we added the EMET 5.5 in that same group policy.  It's been upgrading everyone to 5.5 and applying the new group policy protections that wrote back to the new emet.admx / .adml files that came with the new 5.5 version that I copied over the old admx/adml files from our group policy central store.

    I didn't want to take up more of the users time at that point so I took some screenshots and got out.  I'll have to note this registry issue and also I will have to test other Windows 7 machines to see if this is a problem.  Worst case maybe I have to do some kind of login gpp to create the reg key if the machine os is windows 7.  Why would Microsoft's installer not create all the required keys is beyond me.  Don't they test these things?  I tested but I don't have any issues on any of my Windows 10 machines.

    Saturday, March 5, 2016 4:33 PM
  • Ok I got the sid of the user with the issue and via remote registry checked their hkey\users\sid\software\microsoft\emet registry.  Its there just like its there on my Windows 10 machine.  However when I run EMET on that users machine, I am putting in MY domain admin credentials in order to open it.  However I personally have never logged on that machine to create a profile so I wouldn't have that registry key.  Do you think thats what causes this?

    As long as EMET is running, we control it via GP anyway.

    I'll try adding EMET under HKEY_USERS\.DEFAULT\Software\Microsoft and see if it will just apply to any IT admin that would attempt to authenticate and run EMET gui.
    • Edited by KJSTech1 Saturday, March 5, 2016 4:45 PM
    Saturday, March 5, 2016 4:40 PM
  • has anyone found a "SOLID" fix for this. having to open the registry and change files to open the GUI is not a fix in my opinion.   sure you can script something but that seems ridiculous.  I have this deployed to a test collection of workstations not proceeding until we get a better solution.
    Wednesday, March 23, 2016 3:44 PM
  • Just tried manually installing EMET 5.5 Win 10 Pro

    Faulting application name: EMET_GUI.exe, version: 5.5.5871.31892, time stamp: 0x56aac3a8
    Faulting module name: KERNELBASE.dll, version: 10.0.10586.162, time stamp: 0x56cd45b4
    Exception code: 0xe0434352
    Fault offset: 0x0000000000071f28
    Faulting process id: 0xdf4
    Faulting application start time: 0x01d1b820139dcb87
    Faulting application path: C:\Program Files (x86)\EMET 5.5\EMET_GUI.exe
    Faulting module path: C:\WINDOWS\system32\KERNELBASE.dll
    Report Id: 2ab8d443-c17e-45a4-9f8a-31d5fd0db4b8
    Faulting package full name: 
    Faulting package-relative application ID: 

    -----

    Application: EMET_GUI.exe
    Framework Version: v4.0.30319
    Description: The process was terminated due to an unhandled exception.
    Exception Info: System.Exception
       at HelperLib.Config.GetStringValue(System.String, System.String, Boolean)
       at GraphicalApp.MainForm..ctor()
       at GraphicalApp.Program.RunEmetGUI()
       at GraphicalApp.Program.Main(System.String[])

    Chose Suggested setting and GUI will not open now

    Friday, May 27, 2016 2:02 PM
  • I'll try adding EMET under HKEY_USERS\.DEFAULT\Software\Microsoft and see if it will just apply to any IT admin that would attempt to authenticate and run EMET gui.

    ****

    The above didn't work for me since the key was already there.

    Friday, May 27, 2016 2:05 PM
  • Well this is because EMET5.5 is completely broken. I don't understand how anyone is able to get it to work. Installed 5.5 on my machines because 5.2 had issues with IE11 in Windows 10, and now it's even worse. The EMET_gui.exe crashes on load due to this stupid reg key that is only stored in the elevated users profile.

    Since Microsoft decided that it would be a great idea to force EMET to ALWAYS run as admin, in order to prevent 5.5 from crashing on launch, one would need to run REGEDIT as an admin, add the key, then run EMET using the very _same_ admin account. Then it will work. Worst part about all of this is that there is no way to preemptively add the REG KEY if one is using domain administrator accounts, which makes this absolute garbage to manage and monitor on a clients machine.

    This is ridiculous and needs to be fixed by Microsoft, as it happens on all of my domain machines, Windows 7, Server 2008, Server 2012R2, Windows 8.1, Windows 10, you name it. 
    • Edited by EpicusFuror Friday, June 10, 2016 1:27 PM Font was weird
    Friday, June 10, 2016 1:26 PM
  • Microsoft has acknowledged the workaround, and has also released EMET 5.51 which resolves this issue.

    https://support.microsoft.com/en-au/kb/2458544

    • Proposed as answer by Lachlan Mc Friday, November 4, 2016 12:50 AM
    Friday, November 4, 2016 12:50 AM