> Arg1: 00000000000000f6, Referencing user handle as KernelMode.
This is a new check in Win7’s Verifier.
They just have not well-tested the driver with Win7.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Quality of kernel drivers of well-known vendors like VMWare, McAfee, Juniper. Why does it suck so mu
>They just have not well-tested the driver with Win7.
Yes, I remember that testing my driver for Windows 7 beta I also had this problem. But I fixed it one year ago.
Going further down the road:
6: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
LOCKED_PAGES_TRACKER_CORRUPTION (d9)
Arguments:
Arg1: 0000000000000001, The MDL is being inserted twice on the same process list.
Arg2: fffffa800b3bc180, Address of internal lock tracking structure.
Arg3: fffffa800b339010, Address of memory descriptor list.
Arg4: 0000000000000040, Number of pages locked for the current process.
Debugging Details:
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0xD9
PROCESS_NAME: vmware-vmx.exe
CURRENT_IRQL: 2
LAST_CONTROL_TRANSFER: from fffff80002b9b54d to fffff80002ac7740
STACK_TEXT:
fffff88007a84608 fffff80002b9b54d : 00000000000000d9 0000000000000001 fffffa800b3bc180 fffffa800b339010 : nt!KeBugCheckEx
fffff88007a84610 fffff80002b42443 : fffffa800b3bc180 ffffffffffffffff fffff8a01c1cd100 fffffa800cdae2d0 : nt!MiAddMdlTracker+0xed
fffff88007a84680 fffff8800606eb76 : fffffa800b339010 fffff8a01c1cd101 0000000000000002 0000000000000002 : nt! ?? ::FNODOBFM::string'+0x3be4c fffff88007a84790 fffff88006074b5d : 0000000000040000 0000000000000040 fffffa800ce4c000 fffffa800ce4c001 : vmx86+0x5b76 fffff88007a84810 fffff8800607515f : fffffa800ce4c000 000000000000752c fffff9802c3ccf10 000000000000000c : vmx86+0xbb5d fffff88007a84840 fffff8800606a95a : 00000000000000f0 fffff80000000000 fffffa800cf25090 fffff98088098f10 : vmx86+0xc15f fffff88007a84890 fffff8800606a47f : fffff98088098f10 fffffa800d340cc0 fffffa800a7da700 fffff80002de2707 : vmx86+0x195a fffff88007a84950 fffff80002f6dc16 : fffff98088098ee0 0000000000000002 fffffa800a7da700 fffffa8006fee218 : vmx86+0x147f fffff88007a849b0 fffff80002de2707 : fffffa800cf25090 fffff88007a84ca0 fffffa800cf25090 fffffa800d340cc0 : nt!IovCallDriver+0x566 fffff88007a84a10 fffff80002de2f66 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!IopXxxControlFile+0x607 fffff88007a84b40 fffff80002ac6993 : 0000000000000201 0000000000000000 0000000000000000 0000000000000000 : nt!NtDeviceIoControlFile+0x56 fffff88007a84bb0 0000000077befdca : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13 000000000012ec88 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 00000000`00000000 : 0x77befdca
STACK_COMMAND: kb
FOLLOWUP_IP:
vmx86+5b76
fffff880`0606eb76 90 nop
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: vmx86+5b76
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: vmx86
IMAGE_NAME: vmx86.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4bb41063
FAILURE_BUCKET_ID: X64_0xD9_VRF_vmx86+5b76
BUCKET_ID: X64_0xD9_VRF_vmx86+5b76
Followup: MachineOwner
Yes, I also have noticed that Eset is quite stable and good.
I forgot to mention Norton, actually a year ago I put on youtube video on
how to blue screen Norton Antivirus in 10 minutes:
http://www.youtube.com/watch?v=z_oQkbawoXs
Speaking about McAfee and Trend Micro. In fact, I did mistake in my first
post. When I was speaking about “constant problems” I ment Trend Micro, not
McAfee. It is Trend Micro support who is ignoring me.
–
Volodymyr
“Gary G. Little” a écrit dans le message de groupe de
discussion : xxxxx@ntdev…
> Never used Trend, but I have seen the same problems with Norton, which is
> the worse, and MacAfee. Norton I will not even allow on any of my personal
> machines. What I do use, and what has not failed with the DV settings I
> use
> for testing my WFP driver, has been ESET’s products. This isn’t an ad for
> ESET, simply a declaration of what I have observed.
>
> Gary G. Little
> H (952) 223-1349
> C (952) 454-4629
> xxxxx@comcast.net
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Volodymyr M.
> Shcherbyna
> Sent: Wednesday, October 27, 2010 5:18 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Quality of kernel drivers of well-known vendors like
> VMWare, McAfee, Juniper. Why does it suck so much?
>
> Hello everyone,
>
> Just want to share some feedback I have regarding third party drivers I
> met
> sometimes during my tests. Interesting to know, is it only happening to me
> ?
>
> Or you also saw something simular when dealing with them?
>
> Before releasing my code I always do heavy stress testing with
> antiviruses/fws and I set verifier to verify mine and av/fw driver with
> maximum checks. Mine driver is a typical TDI filter with some additional
> functionality (I set PsLoadImageNotify callbacks to track process creation
> events). (please, no need to point that TDI is depricated, I know that, I
> am
> already taking care of it. This is not the purpose of this post)
>
> So, testing with firewalls I always get BSODs with McAfee, Trend Micro
> (with
> Trend Micro I have less problems, though) in their TDI filters. Even if I
> do
> tests on clean machine (i.e., clean install of XP or Vista and there is NO
> my driver) McAfee BSOD’s with pool corruption assert within 10 minutes of
> stress testing.
>
> (I was also troubleshooting issues with Juniper VPN client which is btw a
> TDI filter. You enable verifier, run it, and you got immidiate BSOD. IIRC
> it
> was related to not marking IRP pending, or something simular.)
>
> Mine stress test tools are simple: create a lot of processes and make a
> lot
> of connections, and it just dies :). I’ve sent request to McAfee about
> this
> problem, but they never actually resolved it. But this is not the point, I
> am interested to know your opinion about quality of those guys.
>
> Today I was experimenting with my VmWare Workstation at home in Windows 7
> x64 and I got a BSOD when doing verification of vmx86.sys driver. The test
> case is very simple:
>
> 1. Fire verifier and set maximum checks for vmx86.sys
>
> 2. Reboot
>
> 3. Start any x86 virtual machine, and voila, you have the following:
>
> DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
> A device driver attempting to corrupt the system has been caught. This is
> because the driver was specified in the registry as being suspect (by the
> administrator) and the kernel has enabled substantial checking of this
> driver.
> If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA
> will be among the most commonly seen crashes.
> Arguments:
> Arg1: 00000000000000f6, Referencing user handle as KernelMode.
> Arg2: 00000000000002e0, Handle value being referenced.
> Arg3: fffffa8005b9fb30, Address of the current process.
> Arg4: fffff880062da398, Address inside the driver that is performing the
> incorrect reference.
>
> Debugging Details:
> ------------------
>
>
> BUGCHECK_STR: 0xc4_f6
>
> CUSTOMER_CRASH_COUNT: 1
>
> DEFAULT_BUCKET_ID: VERIFIER_ENABLED_VISTA_MINIDUMP
>
> PROCESS_NAME: vmware-vmx.exe
>
> CURRENT_IRQL: 0
>
> LAST_CONTROL_TRANSFER: from fffff800035493dc to fffff800030bf740
>
> STACK_TEXT:
> fffff88007953f48 fffff800035493dc : 00000000000000c4 00000000000000f6
> 00000000000002e0 fffffa8005b9fb30 : nt!KeBugCheckEx
> fffff88007953f50 fffff8000355eae4 : 00000000000002e0 fffffa8005b9fb30
> 0000000000000007 fffff78000001000 :
> nt!VerifierBugCheckIfAppropriate+0x3c
> fffff88007953f90 fffff8000331ab40 : fffff6fc00019ae8 fffff880079541f0
> fffffa8004619500 fffffa800c0a2cc8 : nt!VfCheckUserHandle+0x1b4
> fffff88007954070 fffff800033b8ab5 : 0000000000000000 0000000000000000
> 0000000000000000 0000007fffffff00 : nt! ?? ::NNGAKEGL::string'+0x20e2e<br>> fffff88007954140 fffff800033bde4d : fffffa800c0a2b10 fffff880079542a0<br>> fffff6fb00000040 fffffa8004619510 : nt!ObpLookupObjectName+0x1b5<br>> fffff88007954240 fffff8000335d654 : fffff880079544c8 0000000000000000<br>> fffff88007954300 fffff800030bd93d : nt!ObOpenObjectByName+0x1cd<br>> fffff880079542f0 fffff8000335d72e : fffff88007954760 fffff880000f003f<br>> fffff88007954780 fffff8000335d700 : nt!CmCreateKey+0x2e1<br>> fffff88007954460 fffff800030be993 : 0000000000000000 0000000000000000<br>> 0000000000000000 0000000000000000 : nt!NtCreateKey+0x2e<br>> fffff880079544b0 fffff800030baf30 : fffff8000354fb49 fffff88007954780<br>> fffff880079548a0 0000000000261b00 : nt!KiSystemServiceCopyEnd+0x13<br>> fffff880079546b8 fffff8000354fb49 : fffff88007954780 fffff880079548a0<br>> 0000000000261b00 fffff880062e5590 : nt!KiServiceLinkage<br>> fffff880079546c0 fffff880062da398 : 0000000000000000 fffff880062e5590<br>> 0000000000261b00 fffff880079548a0 : nt!VfZwCreateKey+0x99<br>> fffff88007954720 0000000000000000 : fffff880062e5590 0000000000261b00<br>> fffff880079548a0 0000000000000000 : vmx86+0x3398<br>><br>><br>> STACK_COMMAND: kb<br>><br>> FOLLOWUP_IP:<br>> vmx86+3398<br>> fffff880062da398 413bc4 cmp eax,r12d
>
> SYMBOL_STACK_INDEX: b
>
> SYMBOL_NAME: vmx86+3398
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: vmx86
>
> IMAGE_NAME: vmx86.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 4a85fa8c
>
> FAILURE_BUCKET_ID: X64_0xc4_f6_VRF_vmx86+3398
>
> BUCKET_ID: X64_0xc4_f6_VRF_vmx86+3398
>
> Followup: MachineOwner
> ---------
>
> This is not the first bug check I have, I also had something related to
> memory corruption.
>
> Is it a fault of verifier? I doubt. On the other hand, these companies
> (McAfee, VmWare, Juniper) earn millions and spend millions on R&D teams,
> how
> is it possible that they just never do Driver Verifier tests? (At least)
> …
>
> Hope to hear some feedback on this : )
>
> –
> Volodymyr
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> Information from ESET Smart Security, version of virus
> signature
> database 5569 (20101027)
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>
>
>
> Yes, I also have noticed that Eset is quite stable and good.
What about Kaspersky?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Seems to be doing well in terms of stability (I tried Kaspersky Internet Security).
More on subject of Norton: http://www.shcherbyna.com/?p=291 (I forgot that I was writing about this in past)
A field day for the lawyers if something ever happens. Do Norton’s parental
controls still run as a system service?
Regards,
George.
wrote in message news:xxxxx@ntdev…
> More on subject of Norton: http://www.shcherbyna.com/?p=291 (I forgot that
> I was writing about this in past)
>
>> A field day for the lawyers if something ever happens.
Not sure I understood what you mean. You mean that if Norton causes BSODs somewhere in administration (US goverment, France goverment) it will be judged by court?
I doubt. All EULA’s (as well as Microsoft one) say more or less the following: “we carry no responsibility for damage we can make because of imperfection of our code”.
Doesn’t cover negligence.
I doubt. All EULA’s (as well as Microsoft one) say more or less the
following: “we carry no responsibility for damage we can make because of
imperfection of our code”.
Nor does it cover, things like claiming their driver could not be the
cause (I know of a firm that sued another company because the latter’s
driver caused problems that looked like the firms problem). One thing I
have not seen in the discussion as one of the reasons for the drivers
not being PreFast or Verifier clean, is “developer arrogance”. I
believe that a lot of the motivation of OACR was that people in house at
Redmond weren’t using PreFast. When I complain about problems with the
checked build, I get the impression that a lot of driver writers in
Redmond do not use it. In both cases they believe “I know what I am
doing”.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“George M. Garner Jr.” wrote in message
news:xxxxx@ntdev:
> Doesn’t cover negligence.
>
> > I doubt. All EULA’s (as well as Microsoft one) say more or less the
> > following: “we carry no responsibility for damage we can make because of
> > imperfection of our code”.
> >
Hello Don,
I guess problems found by prefast are also detected by verifier. Not quite
directly, but …
When prefasting my code for the very first time I’ve found some intensive
usage of stack by my variables and functions which eventually lead to stack
corruption and this of course will be detected by verifier anyway.
As for legal facts. I don’t know like in US. In Western Europe companies
used to take insurance which covers any damage done by software.
–
Volodymyr
“Don Burn” a écrit dans le message de groupe de discussion :
xxxxx@ntdev…
> Nor does it cover, things like claiming their driver could not be the
> cause (I know of a firm that sued another company because the latter’s
> driver caused problems that looked like the firms problem). One thing I
> have not seen in the discussion as one of the reasons for the drivers not
> being PreFast or Verifier clean, is “developer arrogance”. I believe that
> a lot of the motivation of OACR was that people in house at Redmond
> weren’t using PreFast. When I complain about problems with the checked
> build, I get the impression that a lot of driver writers in Redmond do not
> use it. In both cases they believe “I know what I am doing”.
>
>
> Don Burn (MVP, Windows DKD)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
>
> “George M. Garner Jr.” wrote in message
> news:xxxxx@ntdev:
>
>> Doesn’t cover negligence.
>>
>> > I doubt. All EULA’s (as well as Microsoft one) say more or less the
>> > following: “we carry no responsibility for damage we can make because
>> > of
>> > imperfection of our code”.
>> >
>
>
Actually, the various tools that check quality have differences but some
overlap. My list of all the tools are:
Compile time
/W4 (or /Wall if you are aggressive)
C++ compiler (versus C)
PreFast
PC-Lint
SDV
Run time
Checked Build
Driver Verifier
Call Usage Verifier (aka OSR DDK)
/RTC
/W4 will catch things that the next three catch. C++ actually does not
catch any more than /W4 plus PreFast. PC-Lint can catch things that are
not caught by the others (though mainly in coding style class errors).
Finnally SDV has promise and I use it but it has not found errors for
me.
Checked Build covers a lot more problems than Driver Verifier. Driver
Verifier catches problems that are not caught with the checked build.
CUV can still catch things that neither of the others do. And using
expanded /RTC commands (need to write your own runtimes, can catch
things that the others don’t).
Except for CUV which Microsoft foolishly abandoned, the other are all
usable, and desirable.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Volodymyr M. Shcherbyna” wrote in message
news:xxxxx@ntdev:
> Hello Don,
>
> I guess problems found by prefast are also detected by verifier. Not quite
> directly, but …
>
> When prefasting my code for the very first time I’ve found some intensive
> usage of stack by my variables and functions which eventually lead to stack
> corruption and this of course will be detected by verifier anyway.
>
> As for legal facts. I don’t know like in US. In Western Europe companies
> used to take insurance which covers any damage done by software.
>
> –
> Volodymyr
Hello Doron,
I would also add to this several things:
-
making asserts in #ifdef DBG
-
using kernrate to catch perfomance bottlenecks
I have tons of places where I do my own asserts if I feel something suspicious in behaviour. For example, if delta in time between several pieces of code is bigger than I expect I do KeBugCheckEx with id and subid so that these bugs can be catched easially. I have hundreds of asserts like this.
One of the interesting bug I catched in my asserts is problem with ExUuidCreate: http://www.shcherbyna.com/?p=114 . I could only catch it if I would count number of times ExUuidCreate fails and assert when the count reaches some limit 
My post at blog about ExUuidCreate is confusing.
I agree that ExUuidCreate may touch the buffer when failing. The reason I
gave ExUuidCreate as an example here is following:
I could catch this bug only by asserting when checking return values of the
function. Because even if it fails, it gives you impession that it works, as
it returns some data in output buffer, and you are confused.
–
Volodymyr
a écrit dans le message de groupe de discussion :
xxxxx@ntdev…
> Hello Doron,
>
> I would also add to this several things:
>
> 1. making asserts in #ifdef DBG
>
> 2. using kernrate to catch perfomance bottlenecks
>
> I have tons of places where I do my own asserts if I feel something
> suspicious in behaviour. For example, if delta in time between several
> pieces of code is bigger than I expect I do KeBugCheckEx with id and subid
> so that these bugs can be catched easially. I have hundreds of asserts
> like this.
>
> One of the interesting bug I catched in my asserts is problem with
> ExUuidCreate: http://www.shcherbyna.com/?p=114 . I could only catch it if
> I would count number of times ExUuidCreate fails and assert when the count
> reaches some limit
>
> I would also add to this several things:
- making asserts in #ifdef DBG
I would disagree.
First of all, extensive test suites of checked build are IMHO not worth the time spent. The customers run the free build, this is what must go through the full QA matrix. I personally only build the checked version to catch some particular hard bug.
Second, classic asserts are just plain evil much better way is to check for condition even in release code, and, on failure, abort the code path gently and log an event log message of “Internal error 1000” or such.
A matter of taste though, we are just sharing approaches.
For me, /W4 is used always, PREFast is used on each source control commit, and testing with Verifier (includes the checks for memory leaks) and checked build (on the latest OS at least, which is now 2008 R2) - on each more-or-less serious milestone (other then minor feature addition or a small bug fix).
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Yes, this is maybe a question of taste …
I usually deploy checked version in the my office and catch BSOD’s if any.
Some friendly colleges always live with debug driver + verifier … In
checked build I also have self diagnostics, so I can poll machines to see if
I have problems somewhere (by running helper application on those machine
which ioctls driver for statistics).
Btw, noone mentioned here pooltags. I always use unique tags and always
check them.
–
Volodymyr
“Maxim S. Shatskih” a écrit dans le message de
groupe de discussion : xxxxx@ntdev…
>> I would also add to this several things:
>>
>> 1. making asserts in #ifdef DBG
>
> I would disagree.
>
> First of all, extensive test suites of checked build are IMHO not worth
> the time spent. The customers run the free build, this is what must go
> through the full QA matrix. I personally only build the checked version to
> catch some particular hard bug.
>
> Second, classic asserts are just plain evil much better way is to check
> for condition even in release code, and, on failure, abort the code path
> gently and log an event log message of “Internal error 1000” or such.
>
> A matter of taste though, we are just sharing approaches.
>
> For me, /W4 is used always, PREFast is used on each source control commit,
> and testing with Verifier (includes the checks for memory leaks) and
> checked build (on the latest OS at least, which is now 2008 R2) - on each
> more-or-less serious milestone (other then minor feature addition or a
> small bug fix).
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
Do you use ExFreePoolWithTag and the PROTECTED_POOL flag on the tag? I
forgot this on my previous list, but this is an excellent model for
being sure the memory you free is what you think you are freeing.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Volodymyr M. Shcherbyna” wrote in message
news:xxxxx@ntdev:
> Yes, this is maybe a question of taste …
>
> I usually deploy checked version in the my office and catch BSOD’s if any.
> Some friendly colleges always live with debug driver + verifier … In
> checked build I also have self diagnostics, so I can poll machines to see if
> I have problems somewhere (by running helper application on those machine
> which ioctls driver for statistics).
>
> Btw, noone mentioned here pooltags. I always use unique tags and always
> check them.
>
> –
> Volodymyr
>
> “Maxim S. Shatskih” a écrit dans le message de
> groupe de discussion : xxxxx@ntdev…
> >> I would also add to this several things:
> >>
> >> 1. making asserts in #ifdef DBG
> >
> > I would disagree.
> >
> > First of all, extensive test suites of checked build are IMHO not worth
> > the time spent. The customers run the free build, this is what must go
> > through the full QA matrix. I personally only build the checked version to
> > catch some particular hard bug.
> >
> > Second, classic asserts are just plain evil much better way is to check
> > for condition even in release code, and, on failure, abort the code path
> > gently and log an event log message of “Internal error 1000” or such.
> >
> > A matter of taste though, we are just sharing approaches.
> >
> > For me, /W4 is used always, PREFast is used on each source control commit,
> > and testing with Verifier (includes the checks for memory leaks) and
> > checked build (on the latest OS at least, which is now 2008 R2) - on each
> > more-or-less serious milestone (other then minor feature addition or a
> > small bug fix).
> >
> > –
> > Maxim S. Shatskih
> > Windows DDK MVP
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
Don,
What is the PROTECTED_POOL flag?
Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Thursday, October 28, 2010 7:16 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Quality of kernel drivers of well-known vendors like
VMWare, McAfee, Juniper. Why does it suck so much?
Do you use ExFreePoolWithTag and the PROTECTED_POOL flag on the tag? I
forgot this on my previous list, but this is an excellent model for being
sure the memory you free is what you think you are freeing.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Volodymyr M. Shcherbyna” wrote in message
news:xxxxx@ntdev:
> Yes, this is maybe a question of taste …
>
> I usually deploy checked version in the my office and catch BSOD’s if any.
> Some friendly colleges always live with debug driver + verifier … In
> checked build I also have self diagnostics, so I can poll machines to
> see if I have problems somewhere (by running helper application on
> those machine which ioctls driver for statistics).
>
> Btw, noone mentioned here pooltags. I always use unique tags and
> always check them.
>
> –
> Volodymyr
>
> “Maxim S. Shatskih” a ?crit dans le message
> de groupe de discussion : xxxxx@ntdev…
> >> I would also add to this several things:
> >>
> >> 1. making asserts in #ifdef DBG
> >
> > I would disagree.
> >
> > First of all, extensive test suites of checked build are IMHO not
> > worth the time spent. The customers run the free build, this is what
> > must go through the full QA matrix. I personally only build the
> > checked version to catch some particular hard bug.
> >
> > Second, classic asserts are just plain evil much better way is to
> > check for condition even in release code, and, on failure, abort the
> > code path gently and log an event log message of “Internal error 1000”
or such.
> >
> > A matter of taste though, we are just sharing approaches.
> >
> > For me, /W4 is used always, PREFast is used on each source control
> > commit, and testing with Verifier (includes the checks for memory
> > leaks) and checked build (on the latest OS at least, which is now
> > 2008 R2) - on each more-or-less serious milestone (other then minor
> > feature addition or a small bug fix).
> >
> > –
> > Maxim S. Shatskih
> > Windows DDK MVP
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
From ntddk.h:
//
// If high order bit in Pool tag is set, then must use ExFreePoolWithTag to free
//
#define PROTECTED_POOL 0x80000000
- S
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bill Wandel
Sent: Thursday, October 28, 2010 6:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Quality of kernel drivers of well-known vendors like VMWare, McAfee, Juniper. Why does it suck so much?
Don,
What is the PROTECTED_POOL flag?
Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Thursday, October 28, 2010 7:16 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Quality of kernel drivers of well-known vendors like VMWare, McAfee, Juniper. Why does it suck so much?
Do you use ExFreePoolWithTag and the PROTECTED_POOL flag on the tag? I forgot this on my previous list, but this is an excellent model for being sure the memory you free is what you think you are freeing.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Volodymyr M. Shcherbyna” wrote in message
news:xxxxx@ntdev:
> Yes, this is maybe a question of taste …
>
> I usually deploy checked version in the my office and catch BSOD’s if any.
> Some friendly colleges always live with debug driver + verifier … In
> checked build I also have self diagnostics, so I can poll machines to
> see if I have problems somewhere (by running helper application on
> those machine which ioctls driver for statistics).
>
> Btw, noone mentioned here pooltags. I always use unique tags and
> always check them.
>
> –
> Volodymyr
>
> “Maxim S. Shatskih” a ?crit dans le message
> de groupe de discussion : xxxxx@ntdev…
> >> I would also add to this several things:
> >>
> >> 1. making asserts in #ifdef DBG
> >
> > I would disagree.
> >
> > First of all, extensive test suites of checked build are IMHO not
> > worth the time spent. The customers run the free build, this is what
> > must go through the full QA matrix. I personally only build the
> > checked version to catch some particular hard bug.
> >
> > Second, classic asserts are just plain evil much better way is to
> > check for condition even in release code, and, on failure, abort the
> > code path gently and log an event log message of “Internal error 1000”
or such.
> >
> > A matter of taste though, we are just sharing approaches.
> >
> > For me, /W4 is used always, PREFast is used on each source control
> > commit, and testing with Verifier (includes the checks for memory
> > leaks) and checked build (on the latest OS at least, which is now
> > 2008 R2) - on each more-or-less serious milestone (other then minor
> > feature addition or a small bug fix).
> >
> > –
> > Maxim S. Shatskih
> > Windows DDK MVP
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Thanks. This is not in the WDK documentation.
Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Thursday, October 28, 2010 10:02 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Quality of kernel drivers of well-known vendors like
VMWare, McAfee, Juniper. Why does it suck so much?
From ntddk.h:
//
// If high order bit in Pool tag is set, then must use ExFreePoolWithTag to
free //
#define PROTECTED_POOL 0x80000000
- S
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill Wandel
Sent: Thursday, October 28, 2010 6:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Quality of kernel drivers of well-known vendors like
VMWare, McAfee, Juniper. Why does it suck so much?
Don,
What is the PROTECTED_POOL flag?
Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Thursday, October 28, 2010 7:16 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Quality of kernel drivers of well-known vendors like
VMWare, McAfee, Juniper. Why does it suck so much?
Do you use ExFreePoolWithTag and the PROTECTED_POOL flag on the tag? I
forgot this on my previous list, but this is an excellent model for being
sure the memory you free is what you think you are freeing.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Volodymyr M. Shcherbyna” wrote in message
news:xxxxx@ntdev:
> Yes, this is maybe a question of taste …
>
> I usually deploy checked version in the my office and catch BSOD’s if any.
> Some friendly colleges always live with debug driver + verifier … In
> checked build I also have self diagnostics, so I can poll machines to
> see if I have problems somewhere (by running helper application on
> those machine which ioctls driver for statistics).
>
> Btw, noone mentioned here pooltags. I always use unique tags and
> always check them.
>
> –
> Volodymyr
>
> “Maxim S. Shatskih” a ?crit dans le message
> de groupe de discussion : xxxxx@ntdev…
> >> I would also add to this several things:
> >>
> >> 1. making asserts in #ifdef DBG
> >
> > I would disagree.
> >
> > First of all, extensive test suites of checked build are IMHO not
> > worth the time spent. The customers run the free build, this is what
> > must go through the full QA matrix. I personally only build the
> > checked version to catch some particular hard bug.
> >
> > Second, classic asserts are just plain evil much better way is to
> > check for condition even in release code, and, on failure, abort the
> > code path gently and log an event log message of “Internal error 1000”
or such.
> >
> > A matter of taste though, we are just sharing approaches.
> >
> > For me, /W4 is used always, PREFast is used on each source control
> > commit, and testing with Verifier (includes the checks for memory
> > leaks) and checked build (on the latest OS at least, which is now
> > 2008 R2) - on each more-or-less serious milestone (other then minor
> > feature addition or a small bug fix).
> >
> > –
> > Maxim S. Shatskih
> > Windows DDK MVP
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer