Access violation in interactive service about openvpn HOT 3 CLOSED

ping @selvanair

from openvpn.

Does the value of engine handle at this point the same as the one we got from the open call? We do check for error while opening so it has to be a valid handle. If this shows up only when sonicwall/dco compat issue is present, it could be related, no? Like a broken interface that triggers a crash inside WFP when referred to by block-dns?

Will try installing SonicWall client later.

from openvpn.

I cannot reproduce this as dco adapter works for me and block-dns succeeds with sonicwall client installed. Tried re-installing 2.6.0 as a clean install, deleted dco adapter and recreated both with sonic wall installed. No misbehaviour.

@lev I was tetsing with SonicWall's NetExtender not GlobalVPN... yikes.. Reproduced the crash with the latter installed (and its offensive DNE filter).

Anyway, on re-reading your comment, I realized the initial failure is while adding the filter. In that case we do not add the engine to the undo list, and this undo call during termination of openvpn should not happen at all.

Edit:
It turns out that add_block_dns_filters() succeeds (or at least returns success) in spite of the broken adapter state, so we do save the engine handle in the undo list. But before returning from the service, we try to change the metric of the adapter and fail with "no such element". We dutifully clean up block-dns filters but forget to clear the undo list. When we get a call to undo following openvpn.exe's exit, the undo list has an engine handle that's already freed which causes an access violation in FwpmEngineClose0().

from openvpn.