locked
Emet_conf --refresh crashes after re-install of EMET 3.0 RRS feed

  • Question

  • We have had a couple of workstations that we have installed EMET 3.0 on, uninstalled, then reinstalled 3.0, that crash when I try to run "emet_conf --refresh":

    Unhandled Exception: System.ComponentModel.Win32Exception: The system cannot fin
    d the file specified    at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startIn
    fo)
       at System.Diagnostics.Process.Start()
       at MitigationInterface.SysMitigation_DEP.SetOption(String Option, Boolean Ove
    rride)
       at MitigationInterface.SystemMitigations.ApplyPolicySettings()
       at ConsoleApp.Program.ProcessCommandLineArgs(String[] args)
       at ConsoleApp.Program.Main(String[] args)

    Group policy is used to set EMET configuration in this scenerio.

    Any ideas?

    Thanks,

    Chris

    Monday, March 11, 2013 7:14 PM

Answers

  • Hi Chris,

    Thanks for the extra info.  

    From what I can see, you have done everything right. In an attempt to diagnose the cause of this exception, I have created Sysinternals Process Monitor traces of a successful Group Policy refresh. These files can be downloaded from the following links:

    Windows XP SP3:

    https://skydrive.live.com/redir?resid=669356BE500E17FB!169&authkey=!APAY2JvOwRL6no0

    Windows 7 SP1 64 bit:

    https://skydrive.live.com/redir?resid=669356BE500E17FB!170&authkey=!AIzm2ZxjFhfS6lY

    When the file appears in the browser window, right click it and choose Download.

    These files were created on Windows XP SP3 and Windows 7 SP1 64 bit with EMET 3.0 having been re-installed on both.

    I would like to suggest comparing this successful refresh with an equivalent Process Monitor trace from the workstations that are failing this refresh. Examining the trace for the activities of the EMET_Conf.exe and cmd.exe may point to the file that is missing that causes the exception to be thrown.

    You may wish to exclude cmd.exe from the trace, this can be done by right clicking an event corresponding to cmd.exe and choosing Exclude cmd.exe from the pop-up menu as shown in the following screenshot:

    Direct Link To Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/ExcludeCMD.png

    Examining these traces can be tedious and time consuming but there may be no other way to determine what file emet_conf.exe is trying to call when it fails. This method of troubleshooting was used by Mark Russinovich to diagnose the cause of a failing installation of Microsoft Security Essentials. He was able to compare a successful installation Process Monitor trace with a trace from a failed installation and was then able to determine the cause and resolve the issue. His exact process is detailed in the following blog post:

    http://blogs.technet.com/b/markrussinovich/archive/2012/01/05/3473797.aspx

    Please find below the steps that I carried out on each version of Windows to create these traces. The screenshots shown below are for Windows XP but the same options and steps were followed for Windows 7.

    1. Start Process Monitor by downloading it to a location of your choice, extract the contents of the ZIP file to a folder of your choice.

    For Windows 7: right click Procmon.exe and choose “Run As Administrator.” Click Yes or enter your administrator password to continue if UAC (User Account Control) is enabled.

    For Windows XP: Double click Procmon.exe to open it.

    2. Go to File->Capture Events to stop Process Monitor from capturing data for now.

    Direct Link To Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Nvidia/ProcessMonitor1.png

    3. Next, go to Filter->Filter

    Direct Link To Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Nvidia/ProcessMonitor2.png

    4. Using the drop down menu, choose Process Name and enter emet_conf.exe and cmd.exe, then press the Add button to add each file to the filter list.

    You should now see the entries in the filter list as shown by the following screenshot:

    Direct Link To Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/ProcessMonitor_EMET_Refresh.jpg

    5. For any data that Process Monitor may have already captured, we need to remove this. Go to Edit->Clear Display to clear this data.

    Direct Link To Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Nvidia/ProcessMonitor5.png

    6. Select the following 2 buttons below to only show registry and file activity:

    Direct Link To Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/ProcessMonitorFile_Reg_Activity.jpg

    7. Go to File->Capture Events and run the emet_conf.exe –refresh command.

    8. Stop Process Monitor from capturing events (repeat the first part of step 7, above) only after the EMET Refresh command fails. Choose File->Save and save your trace containing the events from an unsuccessful EMET refresh with a name and in a location of your choice.

    Direct Link To Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/ProcessMonitor_Log_Save.jpg

    Direct Link To Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/ProcessMonitor_Save_Options.jpg

    9. Open a second instance of Process Monitor and compare the failing refresh trace with the successful trace. I suggest placing one instance of Process Monitor at the top of your screen and one at the bottom since you will need the horizontal space to read the events.

    This is a very detailed process and you may or may not wish to carry it out. Unfortunately it is the only remaining suggestion I have since all of the information about the steps you have carried out so far seem perfectly fine. I cannot see a reason why this command is failing.

    If I can be of any further assistance, please let me know. I hope that you are successful in determining the cause of this exception. Thank you.


    • Edited by JamesC_836 Sunday, March 17, 2013 3:37 PM Added hyperlinks for images
    • Marked as answer by Chris Covington LOGIS Tuesday, March 19, 2013 3:38 PM
    Saturday, March 16, 2013 8:45 PM

All replies

  • Hi Chris,

    You most likely know a lot more about Group Policy than I do but since the exception shows that it cannot find the file specified I am going to provide some quick ideas:

    Were the computers restarted after uninstalling EMET 3.0?

    Was the install for “just me” or “everyone” option used? Did this option differ from the previous EMET installation that was removed?

    Is the refresh command running with admin rights?

    Was the System PATH variable set to include the path to the EMET folder? If not, the script must navigate to the EMET folder to run the refresh command.

    Is EMET now installed in a different location than the previous installation?

    Why was EMET 3.0 uninstalled? Could this reason be related to the above exception?

    Are there any other differences (in software/configuration/security policies) you can think of between the workstations that crash when running this command to workstations that run this command perfectly?

    I uninstalled EMET 3.0 on one of my systems, rebooted, re-installed it and tried to reproduce the error. The command completed successfully for my attempt.

    I hope the above suggestions are of some assistance. My apologies that I cannot be of more assistance and for the simplicity of my suggestions.

    Thank you.

    • Edited by JamesC_836 Monday, March 11, 2013 9:42 PM Added extra suggestion
    Monday, March 11, 2013 9:35 PM
  • Hi James,

    Thanks for the response.  Here is more information:

    - EMET was installed and re-installed via group policy's software installation feature (Computer Configuration, Policies, Software Settings, Software installation).  Group policy also pushes out EMET configuration policy, but with no automatic --refresh

    - The computer was restarted afterwards, several times

    - emet_conf --refresh was run manually from cmd.exe started using Run As Adminstrator, when in the EMET directory

    - EMET was uninstalled to diagnose compatibility issues with DEP and legacy applications

    - I can't think of anything else

    Unfortunately, I can't figure out the steps to reproduce, it just happens occasionally when reinstalling and then stays stuck that way.

    Friday, March 15, 2013 4:40 PM
  • Hi Chris,

    Thanks for the extra info.  

    From what I can see, you have done everything right. In an attempt to diagnose the cause of this exception, I have created Sysinternals Process Monitor traces of a successful Group Policy refresh. These files can be downloaded from the following links:

    Windows XP SP3:

    https://skydrive.live.com/redir?resid=669356BE500E17FB!169&authkey=!APAY2JvOwRL6no0

    Windows 7 SP1 64 bit:

    https://skydrive.live.com/redir?resid=669356BE500E17FB!170&authkey=!AIzm2ZxjFhfS6lY

    When the file appears in the browser window, right click it and choose Download.

    These files were created on Windows XP SP3 and Windows 7 SP1 64 bit with EMET 3.0 having been re-installed on both.

    I would like to suggest comparing this successful refresh with an equivalent Process Monitor trace from the workstations that are failing this refresh. Examining the trace for the activities of the EMET_Conf.exe and cmd.exe may point to the file that is missing that causes the exception to be thrown.

    You may wish to exclude cmd.exe from the trace, this can be done by right clicking an event corresponding to cmd.exe and choosing Exclude cmd.exe from the pop-up menu as shown in the following screenshot:

    Direct Link To Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/ExcludeCMD.png

    Examining these traces can be tedious and time consuming but there may be no other way to determine what file emet_conf.exe is trying to call when it fails. This method of troubleshooting was used by Mark Russinovich to diagnose the cause of a failing installation of Microsoft Security Essentials. He was able to compare a successful installation Process Monitor trace with a trace from a failed installation and was then able to determine the cause and resolve the issue. His exact process is detailed in the following blog post:

    http://blogs.technet.com/b/markrussinovich/archive/2012/01/05/3473797.aspx

    Please find below the steps that I carried out on each version of Windows to create these traces. The screenshots shown below are for Windows XP but the same options and steps were followed for Windows 7.

    1. Start Process Monitor by downloading it to a location of your choice, extract the contents of the ZIP file to a folder of your choice.

    For Windows 7: right click Procmon.exe and choose “Run As Administrator.” Click Yes or enter your administrator password to continue if UAC (User Account Control) is enabled.

    For Windows XP: Double click Procmon.exe to open it.

    2. Go to File->Capture Events to stop Process Monitor from capturing data for now.

    Direct Link To Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Nvidia/ProcessMonitor1.png

    3. Next, go to Filter->Filter

    Direct Link To Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Nvidia/ProcessMonitor2.png

    4. Using the drop down menu, choose Process Name and enter emet_conf.exe and cmd.exe, then press the Add button to add each file to the filter list.

    You should now see the entries in the filter list as shown by the following screenshot:

    Direct Link To Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/ProcessMonitor_EMET_Refresh.jpg

    5. For any data that Process Monitor may have already captured, we need to remove this. Go to Edit->Clear Display to clear this data.

    Direct Link To Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Nvidia/ProcessMonitor5.png

    6. Select the following 2 buttons below to only show registry and file activity:

    Direct Link To Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/ProcessMonitorFile_Reg_Activity.jpg

    7. Go to File->Capture Events and run the emet_conf.exe –refresh command.

    8. Stop Process Monitor from capturing events (repeat the first part of step 7, above) only after the EMET Refresh command fails. Choose File->Save and save your trace containing the events from an unsuccessful EMET refresh with a name and in a location of your choice.

    Direct Link To Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/ProcessMonitor_Log_Save.jpg

    Direct Link To Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/ProcessMonitor_Save_Options.jpg

    9. Open a second instance of Process Monitor and compare the failing refresh trace with the successful trace. I suggest placing one instance of Process Monitor at the top of your screen and one at the bottom since you will need the horizontal space to read the events.

    This is a very detailed process and you may or may not wish to carry it out. Unfortunately it is the only remaining suggestion I have since all of the information about the steps you have carried out so far seem perfectly fine. I cannot see a reason why this command is failing.

    If I can be of any further assistance, please let me know. I hope that you are successful in determining the cause of this exception. Thank you.


    • Edited by JamesC_836 Sunday, March 17, 2013 3:37 PM Added hyperlinks for images
    • Marked as answer by Chris Covington LOGIS Tuesday, March 19, 2013 3:38 PM
    Saturday, March 16, 2013 8:45 PM
  • Thank you for the information.

    I looked at the x64 workstation running Windows 7 x64 SP1 where "emet_conf --refresh" crashes with procmon as you suggested.  Right before the registry queries for HKLM\SOFTWARE\Policies\Microsoft\PCHealth\ErrorReporting start, I see a C:\Windows\SysWOW64\bcdedit.exe NameNotFound error (and another for bcdedit.exe.exe).  It does not attempt to look in C:\Windows\System32 for it.  That system has bcdedit.exe in C:\Windows\System32 rather than C:\Windows\SysWOW64, which could be the error. 

    On a good similar system, it does not look in C:\Windows\SysWOW64, just in C:\Windows\System32 and finds it.

    Any ideas on how to tell EMET where to look for bcdedit, and why it might be looking in the wrong place?

    Thanks!

    Monday, March 18, 2013 6:56 PM
  • Hi Chris,

    Unfortunately I don’t know how to have Windows look for bcdedit.exe in the correct folder (i.e. System32 instead of SysWOW64). I suspect that it has something to do with how the environmental variables are set, but I am not totally sure.

    This kind of repair is beyond my level of knowledge. Creating a new user account with Administrator privileges and using it to perform the refresh might solve this, but this issue may be at a deeper level than a user account.

    The following suggestion is a long shot, but it might be worth checking. Please ensure that EMET_Conf.exe and EMET_GUI.exe are not set to run in Compatibility mode. The Compatibility settings for these files should not be enabled at all. Here are the settings from my Windows 7 64 bit SP1, EMET 3.0 installation:

    Direct Link To Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/EMETConf.png

    Direct Link To Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/EMETGUI.png

    One reason why EMET uses bcdedit.exe is to set the system wide DEP status as mentioned in the following thread:

    http://social.technet.microsoft.com/Forums/en-US/emet/thread/ac54e1e4-d11b-4b24-9555-db889727d92d/#de6b4959-dabc-4e7c-942e-e4537b8474af

    From what I can tell, bcdedit.exe is also used for other purposes but I could only interpret the behavior that I mentioned in that thread.

    My apologies that I cannot be of more assistance to you. If you have access to Microsoft Services Premier and Professional Support for EMET, this would be the next level of support that could assist with resolving this issue. The only other means of support is this forum which is used by volunteers like me.

    Official support from Microsoft used to be provided on this forum but the poster named EMET Support has not posted on this forum for 4 months. I am unsure why they have not posted in such a long time, but I hope they return soon.

    I hope this helps. Thank you.

    • Edited by JamesC_836 Tuesday, March 19, 2013 10:58 AM Added extra info
    Monday, March 18, 2013 8:47 PM
  • Thank you James.

    The reason for EMET looking in SysWow64 is a bit beyond me too.  I checked the EMET executables, but none were set with any compatibility mode settings.  The system environment variables also seemed reasonable.

    Here is the fix: mklink c:\windows\syswow64\bcdedit.exe c:\windows\system32\bcdedit.exe

    This is not a great solution, as it does not address the root cause of EMET looking in the wrong directory, but it does allow "emet_conf --refresh" to complete without crashing now. 

    Tuesday, March 19, 2013 3:44 PM
  • Hi Chris,

    I am really glad that you were able to resolve this. Thank you for marking my post as the answer, even when it isn't.

    I will mark your final post in this thread as helpful since it actually resolves the issue. Thank you for posting a workaround for this issue, your work and advice is very much appreciated.

    Tuesday, March 19, 2013 3:49 PM
  • I found the root cause after running into the issue again: .Net framework was being set to run AnyCPU-compiled applications in 32-bit mode on a 64-bit machine, possibly by third-party software that was installed.  That is why EMET (through .Net) was only looking for bcdedit.exe in the c:\Windows\SysWOW64 (32-bit) directory rather than the c:\Windows\System32 (64-bit) directory on the 64-bit machine.  The registry DWORD that controls this is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Enable64bit.  The command to query/set this is C:\Windows\Microsoft.NET\Framework64\v2.0.50727\ldr64.exe (0=32-bit, 1=64-bit).

    Since there may have been third-party program dependencies on that machine requiring .Net 32-bit mode, I ran the mklink command above instead to fix it.

    Friday, June 27, 2014 2:46 PM