Open strictlymike opened 6 years ago
Quite strange, I could call SetLastError(0)
prior to call the actual binding as a, let me say, temporary solution to this. When I'll have a bit more time to spend upon this I'd like to check if the driver itself behaves in the same way, so probably this could be redirected to the WinDivert project.
Looking more closely, I think it might be raise_on_error
/ wrapper
within windivert_dll
(see pydivert/windivert_dll/__init__.py
) that makes the implicit assumption that LastError
will be cleared after exiting in the success case, when I found that its may in fact depend on a previous API call.
To be clear, I think the solution you proposed (calling SetLastError(0)
before calling the actual binding) is appropriate given the fact that raise_on_error
is expecting the value of GetLastError()
to indicate the success or failure status of this operation.
If a prior Windows API function call changes the last error value for the thread,
pydivert.windivert.WinDivert
raises an exception of the same value. I was originally calling an API that I noted was causingGetLastError()
to return 87, and I thought it was a coincidence thatWinDivert.send()
was raising an exception that, when printed, read:But after some testing, I learned that calling
SetLastError(0)
after calling the (unrelated) Windows API I was using yields a successful invocation ofWinDivert.send()
regardless of the result of this other Windows API call.Here is an example where I have deliberately called
SetLastError(1234)
within a dev branch of FakeNet-NG just prior to invoking thesend()
method of aWinDivert
object:I surmise that either
pydivert
orWinDivert
is relying on the value ofGetLastError()
in at least one case where it has not yet called any Windows APIs that would callSetLastError(ERROR_SUCCESS)
.