Via Martin Gudgin:
We've been working on this document for a while, it's great to get it into the public eye. Please send us your feedback.
[Update] Web Services Enhancements 2.0 for Microsoft® .NET (WSE) is posted for
download.
Larry Osterman posted interesting discussion about checking parameters in components - Should I check the parameters to my function?. Currently I'm using school one approach (always check incoming data with IsBadXXXPtr), but:
The way you check for bad pointers on Win32 is by calling the IsBadReadPtr and IsBadWritePtr API. Michael Howard calls these APIs “CrashMyApplication” and “CorruptMemoryAndCrashMySystem” respectively. The problem with IsBadReadPtr/IsBadWritePtr is that they do exactly what they’re advertised as doing: They read and/or write to the memory location specified, with an exception handler wrapped around the read/write. If an exception is thrown, they fail, if not, they succeed.
There are two problems with this. The only thing that IsBadReadPtr/IsBadWritePtr verifies is that at the instant that the API is called, there was valid memory at that location. There’s nothing to prevent another thread in the application from unmapping the virtual address passed into IsBadReadPtr immediately after the call is made. Which means that any error checks you made based on the results of this API aren’t valid (this is called out in the documentation for IsBadWritePtr/IsBadReadPtr).
The other one is worse. What happens if the memory address passed into IsBadReadPtr is a stack guard page (a guard page is a page kept at the bottom of the stack – when the system top level exception handler sees a fault on a guard page, it will grow the threads stack (up to the threads stack limit))? Well, the IsBadReadPtr will catch the guard page exception and will handle it (because IsBadReadPtr handles all exceptions). So the system exception handler doesn’t see the exception. Which means that when that thread later runs, its stack won’t grow past the current limit. By calling IsBadReadPtr in your API, you’ve turned an easily identifiable application bug into a really subtle stack overflow bug that may not be encountered for many minutes (or hours) later. [via Larry Osterman]
Hmm, it seems that I need to move IsBadXXXPtr only to debug asserts in my projects.
Microsoft Identity and Access Management Series available at TechNet and for download:
This collection of technical papers is designed to help organizations understand
identity and access management issues and related solutions that can be achieved
with Microsoft technologies in heterogeneous IT environments.
The Microsoft Identity and Access Management Series replaces the Microsoft Identity and Access Management Solution [via Anil John, via Brian Redmond]