Aside from the sheer comedy of not using RAII in a program to test exception handling, why do you expect a crash in the call to fscanf_s? Access violations only happen when you access pages of memory that hasn't been committed to a process and as your process "owns" everything you're writing to it won't crash.
When one of the scanf family overwrites the buffer it'll damage/destroy the stack for the function it's called in and those that called it. So the crash will only occur
at the earliest when something like these examples happen:
- you dereference a now invalid pointer or reference
- try and return into the middle of somewhere there are no code pages mapped
- you raise an exception that tries to access a trashed exception record [1]
- return somewhere in your process's code you shouldn't and either
-- try and execute an illegal instruction (say you've returned into the middle of it)
-- as the stack won't be a valid one for your function you do any of the things above
As your code doesn't do any of these things until
after the try block has completed there's not a lot of chance of the exception being raised until after the code that's been written to handle it has been and gone.
If you want to test whether win32 structured exceptions are happening and being caught don't arse about with functions from the standard library - do something really brutal and direct:
int *p = 0; *p = 0;
That'll show up really quickly whether your exception filter is working or not.
Cheers,
Ash
[1] for compilers that use code based exceptions
Edit for effing useless indent feature