$^E [the friendly interface to Win32::GetLastError()] often gets set to "overlapped I/O". You should only check $^E or GetLastError() very soon after a function that reports errors via it has failed. If UserGetGroups() didn't fail, or if it isn't documented that it makes error reasons available via $^E or GetLastError(), or if you didn't check $^E soon enough after the failure, then the value of $^E doesn't mean anything.
Checking the Win32API::Net documentation, I see they suggest using GetLastError(). Going further, I check the source code and see that the classic mistake of throwing away the error reason was made so I don't think they tested their assumption about the error reason being available from GetLastError(). The module needs to be patched to add a call to SetLastError() [for most of the XS functions] so that the documentation will be correct.
As things stand, the error reason returned by GetLastError() has nothing to do with UserGetGroups(), whether it failed recently or not.
The easiest way to get at the error reason would be to patch the module as I described and rebuild it, which requires that you get a C compiler. (Just another example of why XS code tends to suck and why one should try very hard to put less code in XS and more in Perl.)
Alternately, you could try working around it with Win32::API (rather awkwardly).
- tye
In reply to Re: Win32API::Net UserGetGroups returns error code 997 (irrelevant)
by tye
in thread Win32API::Net UserGetGroups returns error code 997
by ThorstenHirsch
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |