I have added IRQL_requires_max and other IRQL annotations to find IRQL troubles. And of course I have found some problems and I have already fixed them.
Unfortunately, later while doing some tests with driver verifier turned on, I found a further BUG within my driver. I was calling a function from DISPATCH_LEVEL which needs to be called at PASSIVE_LEVEL. Ok, I fixed it. But why was code analyzer not able to find my problem before?
I have constructed a very simple use-case which shows my problem with code analyzer:
EntryDispatch1 is buggy: EntryDispatch1 is allowed to be called at DISPATCH_LEVEL but calles SubPassive which needs PASSIVE_LEVEL. This problem is found with code analyzer.
EntryDispatch2 is also buggy: But here code analyser does not found any problems. This is because SubDispatch is called before SubPassive. An now we do not get any warnings.
I have tried this with VS2013 and VS2015.
Has anyone an idea why this simple bug is not detected by code analyzer.
you are calling a function that runs only at passive level from a funtion that can run at dispatch level IRQL_requires_max(DISPATCH_LEVEL) VOID EntryDispatch1()
{ SubPassive(); //warning C28118: Wrong IRQL… OK! }
From my personal experience I saw that the code analyzer doesn’t always do
its job unfortunately. I reported a bug in the SAL annotations (where SAL
does not report an off-by one error) at the end of July and it still hasn’t
been fixed.
I suggest you report the bug to Microsoft. Maybe they’ll realize developers
actually want to write more safe code and they’ll actually fix some issues.
I was very enthusiastic when I started implementing SAL in my projects and
I slowly got more & more disappointed when I saw the issues it does not
detect.
Good luck!
On 14 January 2016 at 13:30, wrote:
> Hello Matthias, > > Yes, of course! I am calling a function which needs to be called at > passive level from dispatch level for demonstration of my problem!: > > 1. for EntryDispatch1 code analyzer finds the problem (the call of > SubPassive) > 2. for EntryDispatch2 code analyzer does not find a problem (the call of > SubPassive is also not allowed) > > Why does code analyzer not find the problem? It is a trivial case which > exists in driver code very likely. > > Regards, > Thomas. > > — > NTDEV is sponsored by OSR > > Visit the list online at: < > http://www.osronline.com/showlists.cfm?list=ntdev> > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > software drivers! > Details at http: > > To unsubscribe, visit the List Server section of OSR Online at < > http://www.osronline.com/page.cfm?name=ListServer> ></http:>
Yes, I have already done some SDV sessions. But the above problem is not found by SDV. And indeed, I thinks that there does not exist a SDV rule which checks the correct function invoations according to their IRQL annotations.
I have verified that SDV inspects my buggy code by temorarilly adding a Spinlock-leak which was found by SDV. But the simple wrong IRQL bug was not found!
Do you know a SDV rule which should check correct IRQL between driver internal function invocations? I only can find rules which check the correct IRQL against a predefined set of WDF or WDM framework functions. For example, I am using Bluetooth profile DDI functions which are annotated with IRQL declarations but of curse for which no specific SDV rules exists. Therefore I am afraid, that IRQL are not detected by SDV for functions decorated with IRQL annotations. SDV finds only problems for fixed predefined set of functions.
I am also very concerned about the number of false positives that it detects. I continue to add SAL to all the code I write, but I consider it to be more informative to human readers than anything else.
Especially annoying is the existence of any static local variable causes code analysis to essentially abort on a function. Also annoying is passing a pointer that is member of a struct to a function decorated with Post_ptr_invalid causes warnings about use of the struct itself. It also does not handle situations where loop control is based on more than one correlated variable – which is disappointing because these are exactly the types of loops that most often cause problems. The lock analysis is also broken in some cases and any lock annotations on functions defined in header files always cause false positives – a common practice when defining Lock_XXX wrappers; but I suppose one could always convert these into macros instead although multi-line macros are more error prone to type than inline functions defined in headers
It does do a fairly good job of finding simple buffer overruns on char and WCHAR buffers however and I am not giving up. If for no other reason, than it helps me understand the code I wrote last year (or yesterday).
From: Gurzou Alexandrumailto:xxxxx Sent: January 14, 2016 6:39 AM To: Windows System Software Devs Interest Listmailto:xxxxx Subject: Re: [ntdev] Code analyzer fails a very simple sample with IRQL_requires_max! What is missing?
Hello,
From my personal experience I saw that the code analyzer doesn’t always do its job unfortunately. I reported a bug in the SAL annotations (where SAL does not report an off-by one error) at the end of July and it still hasn’t been fixed. I suggest you report the bug to Microsoft. Maybe they’ll realize developers actually want to write more safe code and they’ll actually fix some issues. I was very enthusiastic when I started implementing SAL in my projects and I slowly got more & more disappointed when I saw the issues it does not detect.
Good luck!
On 14 January 2016 at 13:30, > wrote: Hello Matthias,
Yes, of course! I am calling a function which needs to be called at passive level from dispatch level for demonstration of my problem!:
1. for EntryDispatch1 code analyzer finds the problem (the call of SubPassive) 2. for EntryDispatch2 code analyzer does not find a problem (the call of SubPassive is also not allowed)
Why does code analyzer not find the problem? It is a trivial case which exists in driver code very likely.
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:
— NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:></mailto:xxxxx></mailto:xxxxx></http:>
You should definitely report these problems. Both the lack of warnings AND the false positives.
The internals of the C++ compiler got a major overhaul for VS 2015. This impacted the way all the static analysis tools work. This certainly could have caused a regression in some capabilities for Code Analysis, especially the stuff that’s specific to drivers. I’ve also seen some very basic SAL annotation violations that have not been reported.
By reporting problems in CA and/or SDV you will not be wasting your time. I’m not sure who owns the Driver-specific CA stuff anymore (there was a realignment of responsibilities and I haven’t asked where this now resides) but I DO know for a fact that the folks who own SDV are *very* interested in and *very* responsive to feedback. They took abuse from me for more than 5 years about how SDV wasn’t helpful, and kept working on it and tweaking it and coming back for more feedback… And now SDV has become an indispensable tool.
So… By all means report problems you find. That’s how these things get fixed. And don’t give up on SAL annotations. They’re our last best hope if we’re going to continue to write driver code in C/C++.
I have added IRQL_requires_max and other IRQL annotations to find IRQL
troubles. And of course I have found some problems and I have already fixed
them.
Unfortunately, later while doing some tests with driver verifier turned on, I
found a further BUG within my driver. I was calling a function from
DISPATCH_LEVEL which needs to be called at PASSIVE_LEVEL. Ok, I fixed it. But
why was code analyzer not able to find my problem before?
I have constructed a very simple use-case which shows my problem with code analyzer:
EntryDispatch1 is buggy: EntryDispatch1 is allowed to be called at
DISPATCH_LEVEL but calles SubPassive which needs PASSIVE_LEVEL. This problem
is found with code analyzer.
EntryDispatch2 is also buggy: But here code analyser does not found any
problems. This is because SubDispatch is called before SubPassive. An now we
do not get any warnings.
I have tried this with VS2013 and VS2015.
Has anyone an idea why this simple bug is not detected by code analyzer.
What happens if SubDispatch() restores IRQL to PASSIVE_LEVEL before
returning ? in that case it would be correct to allow SubPassive() to be
called. Consider using IRQL_requires_same to show that SubDispatch()
returns at the same IRQL as it was called at.
i tried it with IRQL_requires_same with the same result; and from the documentation i take, it is required to annotated if a function rises or lowers the IRQL
Let it be written, let it be done. If there is somewhere I can provide meaningful feedback that will generate a response, give me an hour and I will start
From: xxxxx@osr.commailto:xxxxx Sent: January 15, 2016 8:53 AM To: Windows System Software Devs Interest Listmailto:xxxxx Subject: RE:[ntdev] Code analyzer fails a very simple sample with IRQL_requires_max! What is missing?
You should definitely report these problems. Both the lack of warnings AND the false positives.
The internals of the C++ compiler got a major overhaul for VS 2015. This impacted the way all the static analysis tools work. This certainly could have caused a regression in some capabilities for Code Analysis, especially the stuff that’s specific to drivers. I’ve also seen some very basic SAL annotation violations that have not been reported.
By reporting problems in CA and/or SDV you will not be wasting your time. I’m not sure who owns the Driver-specific CA stuff anymore (there was a realignment of responsibilities and I haven’t asked where this now resides) but I DO know for a fact that the folks who own SDV are very interested in and very responsive to feedback. They took abuse from me for more than 5 years about how SDV wasn’t helpful, and kept working on it and tweaking it and coming back for more feedback… And now SDV has become an indispensable tool.
So… By all means report problems you find. That’s how these things get fixed. And don’t give up on SAL annotations. They’re our last best hope if we’re going to continue to write driver code in C/C++.
So we would need to add this assert to all functions with annotation “IRQL_requires_max(DISPATCH_LEVEL)” to find wrong IRQL invocations for Passive level. But this is not a practical solution! And of course, it also changes the local assert set which could lead to other false results.
I do know the right place to report this problems. I have tried this on Microsoft Connect for VS: