EMET 3.5 issue with IE and Windows Snipping tool... RRS feed

  • Question

  • Some technical background for this repeatable issue:

    OS: Windows 7 Professional, SP1 (64-bit), upto date patches
    EMET: version 3.5
    Browser: IE 9.0, ROP protection enabled
    Application: SnippingTool.exe, version 6.1.76

    Issue: When trying to capture some of the content within Internet Explorer with the Snipping tool, IE freezes and EMET Notfier logs this message:

    EMET_DLL module logged the following event:

    EMET encountered an error in 'C:\Program Files (x86)\Internet Explorer\iexplore.exe'
    CallerCheck Failed:
      PID          : 0x1508/5384
      TID          : 1184
      API Name     : kernel32.VirtualAllocEx
      ReturnAddress: 6AF9B294
      CalledAddress: 7644D998
      StackPtr     : 0014DC64

    Capturing image with Snipping tool within any other applications or browsers with ROP protection enabled does not result in this error.

    Disabling all ROP mitigation for IE resolves this issue. Removing the check mark for the mitigation identified as "Caller" only also resolves this issue. Maybe the ROP mitigation of "Caller" is too strict, it is doubtful that the Windows SnippingTool.exe is malicious...

    Wednesday, December 26, 2012 10:31 PM

All replies

  • Hi Secure-BITS,

    From what I can tell, the ROP mitigations are working as intended. From the EMET 3.5 Tech Preview PDF User’s Guide, Page 11:


    Caller checks: EMET will make sure that when a critical function is reached, it is reached via a call instruction rather than a “RET”. This is a very useful mitigation and breaks many ROP gadgets. This mitigation may be incompatible with some programs. Internet Explorer on a fresh Windows Installation works fine with this mitigation


    While IE is mentioned here, it does not mention the Snipping Tools interaction with IE.

    The ROP mitigations are experimental and are part of a Tech Preview version of EMET and so are not yet fully supported. As noted in the PDF User’s Guide Caller Checks and Simulate Execution Flow are the most likely to cause issues but any of the ROP mitigations could also cause an issue so it is already known that they could be too strict. This is also mentioned in the User’s Guide.

    SnippingTool.exe is not malicious but the mitigations trigger EMET to shut down the Sniping Tool since a legitimate action taken by the snipping tool matched what it deems malicious behaviour. Any mitigation can introduce incompatibilities, not just these newer ROP mitigations.

    I would advise you to mention this incompatibility in the following thread:


    My attempts to reproduce this issue with EMET 3.5 Tech Preview with all ROP mitigations enabled for IE and SnippingTool.exe failed. I was using Windows 7 Professional SP1 64 bit with IE 10 Release Preview with Enhanced Protected Mode enabled.

    I also tried the 32 bit version of IE 10 with Enhanced Protected Mode turned off (thus restoring the ability to launch the 32 bit version of IE from C:\Program Files (x86)\Internet Explorer\iexplore.exe). Again no crashes or notifications from EMET Notifier.

    I hope the above information is of assistance to you. If you have any further questions, please do not hesitate to ask.

    Thank you.

    Thursday, December 27, 2012 5:55 PM
  • James, thanks for your advise and issue had been posted in the incomparability thread. Your tests were based on IE 10, while mine was with IE 9.0, OS versions were the same.

    I understand that EMET might be incompatible with some of the programs, that's fine, red the well written PDF guide, and adjustments can be made easily to allow the app to work. What has been puzzling is that IE actually froze the system and the only way out of it was to shutdown IE through the Task Manager. The snipping tool is just an image capture that works similarly to how "Shift+PrtScn" works. On the surface there's no interaction between IE and the snipping tool, nor is the snipping tool a plugin for IE. Evidently, that is not a correct assumption and enabling ROP for IE 9.0 does freeze the system when snipping tool is used to capture images of IE. The print screen and pasting the capture into an image editor works just fine.

    The mitigation tool does not shutdown the snipping tool, it shuts down IE. Forcibly ending IE process does not stop snipping tool; as the matter of fact when the IE process forcibly ended, the captured image becomes available through the snipping tool. Forcibly ending the snipping tool process does not unfreeze the system, it is still frozen until the IE process is forcibly ended. There might be more integration between MS applications than it seems on the surface; however, it is still strange how EMET behaves with IE 9.0 and the snipping tool.

    Sunday, December 30, 2012 4:20 PM
  • Hi Secure-BITS,

    Thanks for your update.

    I have now reverted back to IE9 in an attempt to reproduce this issue. I have now successfully reproduced this issue and all of the behavior that you reported also happened to me. I noticed what you meant by the captured image becomes available when the crashed IE process is ended using Task Manager. After the crash the image within the Snipping Tool was then usable and could be saved to a file.


    Some points to note:

    The 64 bit version of IE 9 is not affected by this issue. A screenshot can be successfully taken.

    Running the 32 bit version of IE 9 with ActiveX filtering enabled or without any add-ons enabled i.e. iexplore.exe –extoff made no difference, the crash still occurred


    The Snipping Tool is actually composed of 2 component processes i.e. SnippingTool.exe and wisptis.exe (the Microsoft Pen and Touch Input Component) to allow annotation of captured screenshots.

    On my test PC both of those processes as well as IE 9 are opted into all mitigations of EMET 3.5 Tech Preview. Of interest to me is that the error in the event logs that you have provided above. According to MSDN VirtualAllocEx is used to reserve or commit memory in a process. This function is often abused via Return Oriented Programming (ROP) to exploit a process

    I tried to discover the reason for this crash by attaching a debugger namely WinDbg to iexplore.exe and separately to snippingtool.exe but I don’t have the knowledge to set up the debugger in the correct manner/configuration. Each time I caused the crash the function call and watch windows of WinDbg would not populate with any additional info (the info that was already present was not relevant). I was specifically looking for calls to VirtualAllocEx

    I set a breakpoint as follows using the following command: kernel32!VirtualAllocEx It did not yield expected results. I had the relevant symbol files (.pdb) available for WinDbg and had set the appropriate _NT_SYMBOL_PATH

    Why the 64 bit version of iexplore.exe does not crash I am not sure. Using Process Monitor from Sysinternals I captured filtered traces of all file, registry, thread, profiling and network activity for iexplore.exe, snippingtool.exe and wisptis.exe for both 32 and 64 bit versions of IE. There was no discernible difference between a trace captured when a screenshot was successfully obtained and a trace that recorded a crash.  The filtered output for these captured traces was easy to examine (it only contained approx. 4000 events) but I could not find anything out of the ordinary in these traces. Of most interest was the registry activity captured in the trace since it provided the only possibly relevant info.

    There was no file, thread or network activity in the traces. The profiling events were not of interest. I examined the calls (call stacks) of events where iexplore.exe and snippingtool or wisptis.exe were adjacent i.e. next to one another in the trace but I could see any calls to VirtualAllocEx within kernel32.dll.

    My educated guess as to why this is happening is that the Snipping Tool is allocating memory that will hold a copy of the same memory in use by IE (since it is trying to take a screenshot of what IE is displaying). The image displayed by IE is present in memory and when a copy of this memory is taken by the Snipping Tool since the call to VirtualAllocEx to store this copy of memory comes from outside the iexplore.exe process, this is considered an exploit and iexplore.exe is terminated.

    For example, the Return Address from your provided event is: 6AF9B294 while the called address is 7644D998. The stack address is 0014DC64 is not within the virtual memory space of the calling function 7644D998. This is why I think a crash occurs and if so, the mitigations are demonstrating expected behavior.

    I could be completely wrong in my reasoning above but someone of my limited experience is unable to resolve this issue. The only way the cause of this crash could be accurately determined is if someone with the appropriate knowledge e.g. Microsoft EMET Support attaches a debugger to either iexplore.exe or snippingtool.exe (you can only attach to one process at a time) and is able to set a breakpoint on a call to VirtualAllocEx. I attempted this but was unsuccessful. This way, the process at fault could be determined i.e. is it iexplore.exe or snippingtool.exe?

    Finally in your post in the compatibility thread, you mention that “It seems that Windows SnippingTool.exe application code isn't "secure" and might be the next attack vector for hackers for Windows”.

    This is incorrect, the code of the SnippingTool.exe is not insecure it is working as intended. Not all applications are compatible with all mitigations. Code written by Microsoft including Windows has been using the Secure Development Lifecycle (SDL) since 2004. The Snipping Tool opts into mitigations such DEP, ASLR and /GS which are code hardening techniques part of the SDL. For more info about the SDL, please see the following link:


    Both IE 9 and the Snipping Tool are trusted Microsoft programs

    My apologies that I have been unable to definitively determine the root cause of this issue but I hope that using the 64 bit version of IE to capture screenshots is a usable workaround. If not please continue disabling the Caller Checks mitigation of EMET 3.5 Tech Preview as you have already been doing.

    Thank you and Happy New Year.

    • Edited by JamesC_836 Monday, March 25, 2013 1:10 PM Further corrections
    Monday, December 31, 2012 5:03 PM
  • I reported that issue via email a few months ago.  They're aware of it.  It was implied that the final version of EMET 3.5 will address it.  In the meanwhile, another useable workaround is to hit the PrintScreen key on the keyboard, paste the image into Paint at full size, then use Snipping Tool on that.
    Friday, January 4, 2013 12:34 AM
  • Hi mechBgon,

    Thanks for your input, I had forgotten to mention the “old” fashioned way of taking a screenshot.

    Thanks very much for the suggestion, it is a perfect workaround. It is also good to know the final version of EMET 3.5 should address this.

    Friday, January 4, 2013 11:19 AM