Hi all,
I have a WDM driver that I would like to test with Static Driver Verifier. I have started with SDV-FailDriver-WDM sample from github, installed VS 2019 Pro and the latest WDK 10.0.22000.1.
And I could build the sample. But Visual Studio 2019->Analyze → Run Code Analysis → Run Code Analysis on fail_driver1 shows NOTHING but two issues.
D:\Src\SDV-FailDriver-WDM\driver\fail_driver1.c(73): warning C28171: The function ‘DriverAddDevice’ has more than one instance of PAGED_CODE or PAGED_CODE_LOCKED.
D:\Src\SDV-FailDriver-WDM\driver\fail_driver1.c(122): warning C28118: The current function is permitted to run at an IRQ level above the maximum permitted for ‘__PREfastPagedCode’ (1). Prior function calls or annotation are inconsistent with use of that function: The current function may need IRQL_requires_max, or it may be that the limit is set by some prior call. Maximum legal IRQL was last set to 2 at line 113.
I was expecting many issues to be caught as described by the sample’s comments.
So, I have added
Then I took another WDK sample kmdfecho, and added the same code RtlZeroMemory(NullPtr, 10); ,ran code analysis, it was caught! Something is NOT correct.
Please see the attached pictures which will give you much needed context I guess.
Does the SDV work with WDK drivers? Is it supported?
My understanding is, Static Driver Verifier is a standalone WDK tool which is integrated into Visual Studio and presented as Run Code Analysis. Is this true or false? If false, what are the differences between these two?
HLK seem to require SDV logs, where should I get the logs from? Specifically, what tools should I run to generate the log file to feed into the WLK test?
Hi Peter, that’s correct. I am doing exactly that. Also note, is the Microsoft sample, has everything pre-decorated correctly to demonstrate how SDV works.
Open your driver project (.vcxProj) file in Visual Studio. From the Driver menu, click Launch Static Driver Verifier….
This opens the Static Driver Verifier application, where you can control, configure, and schedule when Static Driver Verifier performs an analysis.
…
Peter
I could be wrong but with visual studio 2019, there is no such Driver menu available, thus, click Launch Static Driver Verifier is not possible. I was only running Code Analysis for C/C++:
Run Code Analysis for C/C++
To help you determine whether the source code is prepared, run the Code Analysis tool in Visual Studio. The Code Analysis tool checks for function role type declarations, which SDV requires. The Code Analysis tool can help identify any function declarations that might have been missed or warn you when the parameters of the function definition do not match those in the function role type.
Open your driver project in Visual Studio.
From the Build menu, click Run Code Analysis on Solution.
static code analysis is a very important technique - perhaps THE more important technique in software improvement. But it is not a silver bullet and can’t catch everything. There are also several different methodologies for static analysis and several different tool sets that find totally different kinds of flaws. SDV is one such tool and it is unique in that it understands driver concepts like IRQL, but other tools can find other kinds of errors.
It is very annoying that after all the work that MSFT did to invent and promote SAL, they abandoned it so quickly.
> It is very annoying that after all the work that MSFT did to invent and promote SAL, they abandoned it so quickly. They haven’t abandoned it, certainly not for kernel-mode. Peter
Much of what SAL does is either annoyingly unreadable or just replication
of the strict type checking more readily accomplished by compiling in c++
mode with all warnings enabled and fail on warning turned on.
That said, it does still catch some errors, so it is useful.
First let me say that the effectiveness of the latest MSFT compilers and tools (VS2022) with respect to SAL seems to be to be less effective than older tools (VS2017 vintage IIRC)
There are clear problems with the state of any variable that is co-dependent on another one - for example in loop or memory access bounds checking. There are MANY false positives in my code base and I have low confidence that there aren’t false negatives too
There is also no support for any kind of rundown protection or reference tracking or COM and many other things.
But, SAL is far from useless and does not seem to be to be redundant in any respect to any C++ feature. The success macro is immediately useful in describing under what conditions a function should be considered to succeed and the on success and on failure macros also help make it clear what callers should expect about the parameters in those cases. C++ programmers should not expect to care about these points since error handling is expected to be exception based - except in demanding environments where you can’t
and the in reads and out writes macros don’t have equals either as far as I know. Sure the class could throw (or fail) on an out of bounds access - but that would be a run time failure and not something that the compiler could check
I spend almost all of my time reviewing to code of others and I would love it if you can tell me about something that I’m not aware that will make my job easier - or more importantly improve my veracity at doing it.
Much of what SAL does is either annoyingly unreadable or just replication of the strict type checking more readily accomplished by compiling in c++
Thread drift… but, interesting thread drift I think.
Some of what SAL does is subsumed by Modern C++, sure. The problem is that you can’t use most of the most helpful Modern C++ constructs in kernel mode, and the OS APIs are hopelessly mired in straight old C. So, even for input/output argument checking, SAL can add a lot of value. See the classic blog post on this that OSR’s Scott Noone wrote some years back.
For me, one of the most useful things provided by SAL are the locking/concurrency annotations. When working, “guarded_by” is an awesome tool. As is “requires_lock_held”.
First let me say that the effectiveness of the latest MSFT compilers and tools (VS2022) with respect to SAL seems to be to be less effective than older tools
The constant flow of annoying updates to the compiler often seem to leave SAL enforcement in CA in a heap of steaming rubble. I got so annoyed recently with the regressions in SAL enforcement in VS 2019 I just DELETED the guarded_by annotation that signaled a field should only be accessed via interlocked instructions. CA for this was entirely broken.
Having no tools sucks. Having good tools, and then having them randomly taken away from you, is worse.
My current preference is to comment out the concurrency annotations. I don’t want to delete them because they provide important information, but the tools don’t do reasonable things with them - only the humans do. And at least is is a structured form for the comments
I have considered writing something that will check better, but I always get distracted with something else.
