I have simple driver with DispatchIoControl function. Client application calls this function twice using DeviceIoControl: first time passing invalid buffer size, second call is correct. When DispatchIoControl detects incorrect buffer size, it sets pIrp->IoStatus.Status = STATUS_INVALID_BUFFER_SIZE and returns STATUS_INVALID_BUFFER_SIZE. In the next call, function sets pIrp->IoStatus.Status = STATUS_SUCCESS and returns STATUS_SUCCESS.
In the client application first call to DeviceIoControl returns FALSE, GetLastError is 1784 (it’s OK). Second call returns TRUE, but GetLastError still returns 1784 instead of 0. What should I do in the driver code to reset last error?
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
DQoNCg0KDQoNCkknbSBub3QgZW50aXJlbHkgc3VyZSBpZiBJIHVuZGVyc3RhbmQgdGhpcyBjb3Jy
ZWN0bHksIGJ1dCB5b3UncmUgYWN0dWFsbHkNCnRyeWluZyB0byByZWFkIGdldGxhc3RlcnJvciwg
YWx0aG91Z2ggdGhlIGxhc3QgYXR0ZW1wdCB0byBkbyBzb21ldGhpbmcgd2FzDQphIHN1Y2Nlc3M/
DQoNCkkgdGhpbmsgeW91J2xsIGZpbmQgdGhhdCBHZXRMYXN0RXJyb3IgaXMganVzdCB0aGF0LCB0
aGUgbGFzdCBFUlJPUi4gTm90IHRoZQ0KcmVzdWx0IG9mIHRoZSBsYXN0IG9wZXJhdGlvbi4NCg0K
SGVyZSdzIHdoYXQgdGhlIFZpc3VhbCBTdHVkaW8gLk5ldCBoZWxwIGZpbGUgaGFzIHRvIHNheSBv
biB0aGUgc3ViamVjdC4uLg0KDQpZb3Ugc2hvdWxkIGNhbGwgdGhlIEdldExhc3RFcnJvciBmdW5j
dGlvbiBpbW1lZGlhdGVseSB3aGVuIGEgZnVuY3Rpb24ncw0KcmV0dXJuIHZhbHVlIGluZGljYXRl
cyB0aGF0IHN1Y2ggYSBjYWxsIHdpbGwgcmV0dXJuIHVzZWZ1bCBkYXRhLiBUaGF0IGlzDQpiZWNh
dXNlIHNvbWUgZnVuY3Rpb25zIGNhbGwgU2V0TGFzdEVycm9yIHdpdGggYSB6ZXJvIHdoZW4gdGhl
eSBzdWNjZWVkLA0Kd2lwaW5nIG91dCB0aGUgZXJyb3IgY29kZSBzZXQgYnkgdGhlIG1vc3QgcmVj
ZW50bHkgZmFpbGVkIGZ1bmN0aW9uLg0KDQoNCk1vc3QgZnVuY3Rpb25zIHRoYXQgc2V0IHRoZSB0
aHJlYWQncyBsYXN0IGVycm9yIGNvZGUgdmFsdWUgc2V0IGl0IHdoZW4gdGhleQ0KZmFpbDsgYSBm
ZXcgZnVuY3Rpb25zIHNldCBpdCB3aGVuIHRoZXkgc3VjY2VlZC4gRnVuY3Rpb24gZmFpbHVyZSBp
cw0KdHlwaWNhbGx5IGluZGljYXRlZCBieSBhIHJldHVybiB2YWx1ZSBlcnJvciBjb2RlIHN1Y2gg
YXMgemVybywgTlVMTCwgb3Ig4oCTMS4NClNvbWUgZnVuY3Rpb25zIGNhbGwgU2V0TGFzdEVycm9y
IHVuZGVyIGNvbmRpdGlvbnMgb2Ygc3VjY2VzczsgdGhvc2UgY2FzZXMNCmFyZSBub3RlZCBpbiBl
YWNoIGZ1bmN0aW9uJ3MgcmVmZXJlbmNlIHBhZ2UuDQoNCg0KU28sIHByZXN1bWFibHkgdGhlIERl
dmljZUlvQ29udHJvbCBmdW5jdGlvbiB0aGF0IHlvdXIgYXBwbGljYXRpb24gd2lsbCBiZQ0KdXNp
bmcsIGlzbid0IGFjdHVhbGx5IGNhbGxpbmcgU2V0TGFzdEVycm9yIG9uIHN1Y2Nlc3MuIFlvdSBj
b3VsZCBqdXN0IHR3ZWFrDQppdCBieSBjYWxsaW5nIFNldExhc3RFcnJvcigwKSBiZWZvcmUgeW91
IGNhbGwgdGhlIERldmljZUlvQ29udHJvbC4gQnV0IHRoZQ0KY29ycmVjdCB3YXkgdG8gc29sdmUg
dGhpcyBpcyB0byBOT1QgQ0FMTCBHZXRMYXN0RXJyb3Igd2hlbiB0aGUgbGFzdA0Kb3BlcmF0aW9u
IHdhcyBhIHN1Y2Nlc3MsIGJlY2F1c2UgaXQgaXMgbWVhbmluZ2xlc3MuDQoNCg0KLS0NCg0KDQpN
YXRzDQoNCmJvdW5jZS0xOTE0MjUtMTQwNzlAbGlzdHMub3NyLmNvbSB3cm90ZSBvbiAxMC8yNi8y
MDA0IDAxOjM2OjQ1IFBNOg0KDQo+IEkgaGF2ZSBzaW1wbGUgZHJpdmVyIHdpdGggRGlzcGF0Y2hJ
b0NvbnRyb2wgZnVuY3Rpb24uIENsaWVudA0KPiBhcHBsaWNhdGlvbiBjYWxscyB0aGlzIGZ1bmN0
aW9uIHR3aWNlIHVzaW5nIERldmljZUlvQ29udHJvbDogZmlyc3QNCj4gdGltZSBwYXNzaW5nIGlu
dmFsaWQgYnVmZmVyIHNpemUsIHNlY29uZCBjYWxsIGlzIGNvcnJlY3QuIFdoZW4NCj4gRGlzcGF0
Y2hJb0NvbnRyb2wgZGV0ZWN0cyBpbmNvcnJlY3QgYnVmZmVyIHNpemUsIGl0IHNldHMNCj4gcEly
cC0+SW9TdGF0dXMuU3RhdHVzID0gU1RBVFVTX0lOVkFMSURfQlVGRkVSX1NJWkUgYW5kIHJldHVy
bnMNCj4gU1RBVFVTX0lOVkFMSURfQlVGRkVSX1NJWkUuIEluIHRoZSBuZXh0IGNhbGwsIGZ1bmN0
aW9uIHNldHMNCj4gcElycC0+SW9TdGF0dXMuU3RhdHVzID0gU1RBVFVTX1NVQ0NFU1MgYW5kIHJl
dHVybnMgU1RBVFVTX1NVQ0NFU1MuDQo+IEluIHRoZSBjbGllbnQgYXBwbGljYXRpb24gZmlyc3Qg
Y2FsbCB0byBEZXZpY2VJb0NvbnRyb2wgcmV0dXJucw0KPiBGQUxTRSwgR2V0TGFzdEVycm9yIGlz
IDE3ODQgKGl0J3MgT0spLiBTZWNvbmQgY2FsbCByZXR1cm5zIFRSVUUsIGJ1dA0KPiBHZXRMYXN0
RXJyb3Igc3RpbGwgcmV0dXJucyAxNzg0IGluc3RlYWQgb2YgMC4gV2hhdCBzaG91bGQgSSBkbyBp
bg0KPiB0aGUgZHJpdmVyIGNvZGUgdG8gcmVzZXQgbGFzdCBlcnJvcj8NCj4gRG8geW91IFlhaG9v
IT8NCj4gWWFob28hIE1haWwgQWRkcmVzcyBBdXRvQ29tcGxldGUgLSBZb3Ugc3RhcnQuIFdlIGZp
bmlzaC4gLS0tDQo+IFF1ZXN0aW9ucz8gRmlyc3QgY2hlY2sgdGhlIEtlcm5lbCBEcml2ZXIgRkFR
IGF0IGh0dHA6Ly93d3cuDQo+IG9zcm9ubGluZS5jb20vYXJ0aWNsZS5jZm0/aWQ9MjU2IFlvdSBh
cmUgY3VycmVudGx5IHN1YnNjcmliZWQgdG8NCj4gbnRkZXYgYXM6IG1hdHMucGV0ZXJzc29uQDNk
bGFicy5jb20gVG8gdW5zdWJzY3JpYmUgc2VuZCBhIGJsYW5rDQo+IGVtYWlsIHRvIGxlYXZlLW50
ZGV2LTE0MDc5Q0BsaXN0cy5vc3IuY29tDQo+IEZvcndhcmRTb3VyY2VJRDpOVDAwMDA2MEFF
You are right, thanks. GetLastError should be called only if last call fails.
Mats PETERSSON wrote:
I’m not entirely sure if I understand this correctly, but you’re actually
trying to read getlasterror, although the last attempt to do something was
a success?
I think you’ll find that GetLastError is just that, the last ERROR. Not the
result of the last operation.
Here’s what the Visual Studio .Net help file has to say on the subject…
You should call the GetLastError function immediately when a function’s
return value indicates that such a call will return useful data. That is
because some functions call SetLastError with a zero when they succeed,
wiping out the error code set by the most recently failed function.
Most functions that set the thread’s last error code value set it when they
fail; a few functions set it when they succeed. Function failure is
typically indicated by a return value error code such as zero, NULL, or –1.
Some functions call SetLastError under conditions of success; those cases
are noted in each function’s reference page.
So, presumably the DeviceIoControl function that your application will be
using, isn’t actually calling SetLastError on success. You could just tweak
it by calling SetLastError(0) before you call the DeviceIoControl. But the
correct way to solve this is to NOT CALL GetLastError when the last
operation was a success, because it is meaningless.
–
Mats
xxxxx@lists.osr.com wrote on 10/26/2004 01:36:45 PM:
> I have simple driver with DispatchIoControl function. Client
> application calls this function twice using DeviceIoControl: first
> time passing invalid buffer size, second call is correct. When
> DispatchIoControl detects incorrect buffer size, it sets
> pIrp->IoStatus.Status = STATUS_INVALID_BUFFER_SIZE and returns
> STATUS_INVALID_BUFFER_SIZE. In the next call, function sets
> pIrp->IoStatus.Status = STATUS_SUCCESS and returns STATUS_SUCCESS.
> In the client application first call to DeviceIoControl returns
> FALSE, GetLastError is 1784 (it’s OK). Second call returns TRUE, but
> GetLastError still returns 1784 instead of 0. What should I do in
> the driver code to reset last error?
> Do you Yahoo!?
> Yahoo! Mail Address AutoComplete - You start. We finish. —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256 You are currently subscribed to
> ntdev as: xxxxx@3dlabs.com To unsubscribe send a blank
> email to xxxxx@lists.osr.com
> ForwardSourceID:NT000060AE
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to $subst(‘List.Name’) as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to $subst(‘Email.UnSub’)
---------------------------------
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
Just as an aside… You should also be careful not to call anything else
before you call GetLastError() to get the failure code.
As some things you would not expect to modify the last error actually do.
For example I’ve seen something like printf actually setting last error to success.
Since getting caught like that before these days I normally do something like…
lResult = function()
dwLastError = GetLastError();
if(lResult == ERROR_IT_DIDNT_WORK)
{
< do stuff using last error >
}
BR,
Rob Linegar
Software Engineer
Data Encryption Systems Limited
www.des.co.uk | www.deslock.com
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Alex Farber
Sent: 26 October 2004 14:11
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] GetLastError is not reset
You are right, thanks. GetLastError should be called only if last call fails.
Mats PETERSSON wrote:
I’m not entirely sure if I understand this correctly, but you’re actually
trying to read getlasterror, although the last attempt to do something was
a success?
I think you’ll find that GetLastError is just that, the last ERROR. Not the
result of the last operation.
Here’s what the Visual Studio .Net help file has to say on the subject…
You should call the GetLastError function immediately when a function’s
return value indicates that such a call will return useful data. That is
because some functions call SetLastError with a zero when they succeed,
wiping out the error code set by the most recently failed function.
Most functions that set the thread’s last error code value set it when they
fail; a few functions set it when they succeed. Function failure is
typically indicated by a return value error code such as zero, NULL, or –1.
Some functions call SetLastError under conditions of success; those cases
are noted in each function’s reference page.
So, presumably the DeviceIoControl function that your application will be
using, isn’t actually calling SetLastError on success. You could just tweak
it by calling SetLastError(0) before you call the DeviceIoControl. But the
correct way to solve this is to NOT CALL GetLastError when the last
operation was a success, because it is meaningless.
–
Mats
xxxxx@lists.osr.com wrote on 10/26/2004 01:36:45 PM:
> I have simple driver with DispatchIoControl function. Client
> application calls this function twice using DeviceIoControl: first
> time passing invalid buffer size, second call is correct. When
> DispatchIoControl detects incorrect buffer size, it sets
> pIrp->IoStatus.Status = STATUS_INVALID_BUFFER_SIZE and returns
> STATUS_INVALID_BUFFER_SIZE. In the next call, function sets
> pIrp->IoStatus.Status = STATUS_SUCCESS and returns STATUS_SUCCESS.
> In the client application first call to DeviceIoControl returns
> FALSE, GetLastError is 1784 (it’s OK). Second call returns TRUE, but
> GetLastError still returns 1784 instead of 0. What should I do in
> the driver code to reset last error?
> Do you Yahoo!?
> Yahoo! Mail Address AutoComplete - You start. We finish. —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256 You are currently subscribed to
> ntdev as: xxxxx@3dlabs.com To unsubscribe send a blank
> email to xxxxx@lists.osr.com
> ForwardSourceID:NT000060AE
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@des.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com
________________________________
Do you Yahoo!?
Yahoo! Mail http: - You care about security. So do we. — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: xxxxx@des.co.uk To unsubscribe send a blank email to xxxxx@lists.osr.com</http:>