when built with VS2013 you can't catch an x64 fault on jumping to an invalid address?

_From [bruen...@google.com](https://code.google.com/u/109494838902877177630/) on April 10, 2014 15:06:45_

When built with VS2013, x64 security-common.retnonexisting fails. It
fails natively as well:

% suite/tests/bin/security-common.retnonexisting.exe
starting good function
in foo
first foo a=1
in foo
second foo a=2
starting bad function
looking at ring 0x0000000000000001
Segmentation fault

Can't seem to catch the fault. I can catch a write fault -- just not this
jmp-to-0x1 fault. Local __try doesn't do it either. Debugger is no help
as usual with exception handling problems.

We seem to be linking with "/safeseh:no" but removing it makes no difference.
A simple build from cmdline doesn't fix it:
% cd ~/dr/build_suite/build_debug-internal-64/suite/tests
% cl /Zi /Febin/security-common.retnonexisting.exe ../../../../git/src/suite/tests/security-common/retnonexisting.c /I../../../../git/src/suite/tests /I../.. bin/tools.lib

Doing the same thing after "compilerVS2012_64" => the test works fine.

Why is this limited to VS2013?

Under DR, DR forges the exception, but the app doesn't even catch that.
The SEH code in ntdll goes and does a fatal NtRaiseException.
This happens even if I change the forged pc to be a real valid pc!
:
looking at ring 0x0000000000000001

Segmentation fault

I'm stumped. I thought that even if there's no entry in the SEH64 table (perhaps explaining the failure of __try to work), you could still catch faults at the top level. And given that this works when built with VS2012 -- what's going on?

_Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1423_