We have checked the Windows 8 Driver Samples pack with our analyzer PVS-Studio and found various bugs in its samples. There is nothing horrible about it - bugs can be found everywhere, so the title of this article may sound a bit high-flown. But these particular errors may be really dangerous, as it is a usual practice for developers to use demo samples as a basis for their own projects or borrow code fragments from them.
Try MyIntelliAccount Cloud Accounting Software As A Service Solution Risk Fre...
Why Windows 8 drivers are buggy
1. Why Windows 8 drivers are buggy
Author: Andrey Karpov
Date: 30.04.2013
We have checked the Windows 8 Driver Samples pack with our analyzer PVS-Studio and found various
bugs in its samples. There is nothing horrible about it - bugs can be found everywhere, so the title of this
article may sound a bit high-flown. But these particular errors may be really dangerous, as it is a usual
practice for developers to use demo samples as a basis for their own projects or borrow code fragments
from them.
Windows 8 Driver Samples
Windows 8 Driver Samples is a pack of 283 independent solutions. This fact made our task somewhat
difficult, as we absolutely didn't feel like opening and checking all the solutions (*.sln files) one by one.
We investigated the issue and found out that we were not alone to face it. On programmers' forums you
may often come across the question how to unite several solutions into one. This task appears to be
relatively easy to fulfill. Those interested, please see this post: "How to unite several separate projects
into one general Visual Studio solution (.sln file): One Solution to Rule Them All".
Microsoft developers create very high-quality code. The Casablanca project's check results are a good
proof of that. Creating samples, however, seems to be a lower-priority task for them. I suspect they
don't use the static analysis technology or any other methods of quality monitoring when developing
these projects. A similar situation was with the IPP Samples collection created by Intel. As our checks
have shown, it contains quite a number of bugs (checks 1, 2, 3).
Bugs in samples are not that critical as bugs in real-life software. Nevertheless, bugs can migrate from
samples to real-life projects and cause developers a lot of troubles. Even within the Windows 8 Driver
Samples pack we found identical bugs. The reason is obvious: copying-and-pasting a code fragment from
a nearby sample. In the same way these errors will get into real-life drivers.
Now let's see what interesting issues can be found in Windows 8 Driver Samples. Analysis was
performed with the PVS-Studio 5.03 analyzer. As usually, let me point out that I'll cite only those
fragments which I found undoubtedly suspicious. Also, I only scanned through many of the diagnostic
messages, so if any of the sample collection's developers notices this post, please don't limit yourself to
reading the information given here, and consider analyzing your project more thoroughly.
Note. Visual Studio doesn't provide API for projects implemented as an extension of the standard Visual
C++ project model. This is just the case with the driver development projects. That's why you'll need to
additionally customize PVS-Studio to check your drivers, namely: you'll need to integrate PVS-Studio into
MSBuild. To learn more about the MSBuild integration mode, see these sources:
• Blog. Using PVS-Studio with huge projects (MSBuild integration)
• Documentation. Direct integration of PVS-Studio into MSBuild's build process. MSBuild
integration mode in Visual Studio IDE.
2. Unnecessary semicolon ';'
NDIS_STATUS HwSetPowerMgmtMode(....)
{
....
if (!HW_MULTIPLE_MAC_ENABLED(Hw) &&
(PMMode->dot11PowerMode != dot11_power_mode_unknown));
{
NdisMoveMemory(&Hw->MacState.PowerMgmtMode, PMMode,
sizeof(DOT11_POWER_MGMT_MODE));
HalSetPowerMgmtMode(Hw->Hal, PMMode);
}
....
}
V529 Odd semicolon ';' after 'if' operator. hw_mac.c 95
Note the semicolon here: "...unknown));". It causes the code following it to be executed all the time,
regardless of the condition.
Poor ASSERT
VOID MPCreateProgrammableFilter(....)
{
....
ASSERT (0 < dwMaskSize <5);
....
}
V562 It's odd to compare 0 or 1 with a value of 5: 0 < dwMaskSize < 5. nic_pm.c 825
No comments.
Strange initialization function
NTSTATUS UartInitContext(_In_ WDFDEVICE Device)
{
....
pDevExt->WdfDevice;
3. ....
}
V607 Ownerless expression 'pDevExt->WdfDevice'. uart16550pc.cpp 58
I suspect the developers forgot to initialize the variable 'pDevExt->WdfDevice' in the function
UartInitContext (). I cannot say for sure what it should be initialized with.
A misprint
BOOLEAN DsmpFindSupportedDevice(....)
{
WCHAR tempString[32];
....
tempString[(sizeof(tempString) /
sizeof(tempString)) - 1] = L'0';
....
}
V501 There are identical sub-expressions 'sizeof (tempString)' to the left and to the right of the '/'
operator. utils.c 931
A misprint will cause the null terminator to be written at the beginning of the string instead of its end.
The size of the sizeof(tempString) buffer must be divided by the size of one character. But it is divided by
itself instead. This is the fixed code:
tempString[(sizeof(tempString) /
sizeof(tempString[0])) - 1] = L'0';
The programmer forgot that a string consists of WCHAR characters
HRESULT CDot11SampleExtUI::CreateSecurityProperties(....)
{
....
WCHAR wbuf[128];
....
ZeroMemory(wbuf, 128);
....
4. }
V512 A call of the 'memset' function will lead to underflow of the buffer 'wbuf'. ihvsampleextui.cpp 288
The ZeroMemory() function will empty only half of the buffer 'wbuf'. Since this code refers to the
'CreateSecurityProperties()' function, we may say we have a potential vulnerability here. This is the fixed
code:
ZeroMemory(wbuf, 128 * sizeof(WCHAR));
Another bug of that kind:
typedef struct _DEVICE_INFO
{
....
WCHAR UnicodeSourceIp[MAX_LEN];
WCHAR UnicodeDestIp[MAX_LEN];
....
} DEVICE_INFO, *PDEVICE_INFO;
PDEVICE_INFO FindDeviceInfo(....)
{
....
PDEVICE_INFO deviceInfo = NULL;
....
memcpy(deviceInfo->UnicodeSourceIp,
InputInfo->SourceIp, MAX_LEN);
memcpy(deviceInfo->UnicodeDestIp,
InputInfo->DestIp, MAX_LEN);
....
}
V512 A call of the 'memcpy' function will lead to underflow of the buffer 'deviceInfo->UnicodeSourceIp'.
testapp.c 729
V512 A call of the 'memcpy' function will lead to underflow of the buffer 'deviceInfo->UnicodeDestIp'.
testapp.c 730
5. Only half of a string is copied. The analyzer generated some other V512 messages as well, but I would
have to examine the code more thoroughly to judge whether those were genuine bugs. But I can't do
that: I have a line of projects waiting to be checked.
A recheck
I don't think I can cite the code fragment in full. It contains very long names like
"WFPSAMPLER_CALLOUT_BASIC_ACTION_BLOCK_AT_INBOUND_MAC_FRAME_NATIVE". Such long lines
will break the article's format when publishing it on our viva64.com website. So let me just give you a
description of the bug. The function KrnlHlprExposedCalloutToString() contains the following code:
else if (A == &inbound)
str = "inbound";
else if (A == &inbound)
str = "outbound";
It is meaningless because the second 'if' operator will never be executed. This code fragment is to be
found in the helperfunctions_exposedcallouts.cpp file several times. It must be copy-paste. Here is the
list of these fragments' locations:
• V517 The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical
error presence. Check lines: 556, 558. helperfunctions_exposedcallouts.cpp 556
• V517 The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical
error presence. Check lines: 649, 651. helperfunctions_exposedcallouts.cpp 649
• V517 The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical
error presence. Check lines: 742, 744. helperfunctions_exposedcallouts.cpp 742
• V517 The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical
error presence. Check lines: 835, 837. helperfunctions_exposedcallouts.cpp 835
• V517 The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical
error presence. Check lines: 908, 910. helperfunctions_exposedcallouts.cpp 908
• V517 The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical
error presence. Check lines: 981, 983. helperfunctions_exposedcallouts.cpp 981
• V517 The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical
error presence. Check lines: 1055, 1057. helperfunctions_exposedcallouts.cpp 1055
This is another example of a recheck.
HRESULT CSensor::HandleSetReportingAndPowerStates(....)
{
....
else if (SENSOR_POWER_STATE_LOW_POWER == ulCurrentPowerState)
{
6. Trace(TRACE_LEVEL_ERROR,
"%s Power State value is not correct = LOW_POWER, "
"hr = %!HRESULT!", m_SensorName, hr);
}
else if (SENSOR_POWER_STATE_LOW_POWER == ulCurrentPowerState)
{
Trace(TRACE_LEVEL_ERROR,
"%s Power State value is not correct = FULL_POWER, "
"hr = %!HRESULT!", m_SensorName, hr);
}
....
}
V517 The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical error
presence. Check lines: 5641, 5645. sensor.cpp 5641
I believe the second check must look like this:
else if (SENSOR_POWER_STATE_FULL_POWER == ulCurrentPowerState)
One-time loop
NDIS_STATUS AmSetApBeaconMode(....)
{
....
while (BeaconEnabled != AssocMgr->BeaconEnabled)
{
ndisStatus = ....;
if (NDIS_STATUS_SUCCESS != ndisStatus)
{
break;
}
AssocMgr->BeaconEnabled = BeaconEnabled;
break;
}
7. ....
}
V612 An unconditional 'break' within a loop. ap_assocmgr.c 1817
The loop body is executed no more than once. I find the 'break' operator at the end unnecessary.
Incorrect swap?
NTSTATUS FatSetDispositionInfo (....)
{
....
TmpChar = LocalBuffer[0];
LocalBuffer[0] = TmpChar;
....
}
V587 An odd sequence of assignments of this kind: A = B; B = A;. Check lines: 2572, 2573. fileinfo.c 2573
Strange and meaningless code. Perhaps the programmer wanted to swap the "LocalBuffer[0]" array
item's value for another variable. But something was messed up.
A condition not affecting anything
NDIS_STATUS Hw11QueryDiversitySelectionRX(....)
{
//
// Determine the PHY that the user wants to query
//
if (SelectedPhy)
return HwQueryDiversitySelectionRX(HwMac->Hw,
HwMac->SelectedPhyId,
MaxEntries,
Dot11DiversitySelectionRXList
);
8. else
return HwQueryDiversitySelectionRX(HwMac->Hw,
HwMac->SelectedPhyId,
MaxEntries,
Dot11DiversitySelectionRXList
);
}
V523 The 'then' statement is equivalent to the 'else' statement. hw_oids.c 1043
The value of the 'SelectedPhy' variable is of no importance: one and the same action is executed all the
time. I'm not sure whether this is an error. But the code is very suspicious. Other strange fragments:
• V523 The 'then' statement is equivalent to the 'else' statement. fail_driver1.c 188
• V523 The 'then' statement is equivalent to the 'else' statement. simgpio_i2c.c 2253
• V523 The 'then' statement is equivalent to the 'else' statement. simgpio.c 2181
Restoring settings incorrectly
If you want to disable warnings for a time, you should use a sequence of the following directives:
#pragma warning(push)
#pragma warning(disable: XXX)
....
#pragma warning(pop)
But programmers often do it in a simpler way:
#pragma warning(disable:XXX)
....
#pragma warning(default:XXX)
This practice is bad because the warning output state you set earlier could be different from the default
state. Therefore, the #pragma warning(default:XXX) directive may result in showing warnings you don't
want or, on the contrary, hiding those messages you need.
There are several fragments in Windows 8 Driver Samples where warnings are suppressed in such a poor
manner. For example:
// disable nameless struct/union warnings
#pragma warning(disable:4201)
#include <wdf.h>
9. #pragma warning(default:4201)
V665 Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The '#pragma
warning(push/pop)' should be used instead. Check lines: 23, 25. common.h 25
Here is the list of all the rest fragments where warnings are disabled incorrectly:
• V665 Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The
'#pragma warning(push/pop)' should be used instead. Check lines: 25, 29. protnotify.cpp 29
• V665 Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The
'#pragma warning(push/pop)' should be used instead. Check lines: 27, 29. common.h 29
• V665 Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The
'#pragma warning(push/pop)' should be used instead. Check lines: 30, 34. hidkmdf.c 34
• V665 Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The
'#pragma warning(push/pop)' should be used instead. Check lines: 446, 450. kbfiltr.c 450
• V665 Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The
'#pragma warning(push/pop)' should be used instead. Check lines: 48, 58. trace.h 58
• V665 Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The
'#pragma warning(push/pop)' should be used instead. Check lines: 175, 186. reg9656.h 186
• V665 Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The
'#pragma warning(push/pop)' should be used instead. Check lines: 3, 8. precomp.h 8
• V665 Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The
'#pragma warning(push/pop)' should be used instead. Check lines: 118, 128. trace.h 128
• V665 Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The
'#pragma warning(push/pop)' should be used instead. Check lines: 27, 33. precomp.h 33
• V665 Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The
'#pragma warning(push/pop)' should be used instead. Check lines: 57, 79. usb_hw.h 79
• V665 Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The
'#pragma warning(push/pop)' should be used instead. Check lines: 2497, 2499. pnp.c 2499
• V665 Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The
'#pragma warning(push/pop)' should be used instead. Check lines: 35, 38. hidumdf.c 38
• V665 Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The
'#pragma warning(push/pop)' should be used instead. Check lines: 47, 54. kmdf_vdev_sample.h
54
• V665 Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The
'#pragma warning(push/pop)' should be used instead. Check lines: 21, 25. kmdf_vdev.h 25
• V665 Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The
'#pragma warning(push/pop)' should be used instead. Check lines: 57, 79. usb_hw.h 79
• V665 Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The
'#pragma warning(push/pop)' should be used instead. Check lines: 374, 1099. uvcdesc.h 1099
• V665 Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The
'#pragma warning(push/pop)' should be used instead. Check lines: 566, 575. uvcview.c 575
• V665 Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The
'#pragma warning(push/pop)' should be used instead. Check lines: 62, 84. usb_hw.h 84
• V665 Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The
'#pragma warning(push/pop)' should be used instead. Check lines: 589, 604. wsksmple.c 604
10. A potential infinity loop
VOID HwFillRateElement(....)
{
UCHAR i, j;
....
for (i = 0; (i < basicRateSet->uRateSetLength) &&
(i < 256); i++)
{
rate[i] = 0x80 | basicRateSet->ucRateSet[i];
}
....
}
V547 Expression 'i < 256' is always true. The value range of unsigned char type: [0, 255]. hw_mac.c 1946
An infinity loop may occur here. The 'i' variable has the UCHAR type. It means that its value range is
from 0 to 255, that is, any of its values is always below 256. The loop appears to be limited only by the (i
< basicRateSet->uRateSetLength) condition.
A similar bug can be found in this fragment:
VOID HwFillRateElement(....)
{
....
UCHAR rate[256];
UCHAR rateNum;
....
if (rateNum == sizeof(rate) / sizeof(UCHAR))
break;
....
}
V547 Expression is always false. The value range of unsigned char type: [0, 255]. hw_mac.c 1971
The "sizeof(rate) / sizeof(UCHAR)" expression equals 256. The 'rateNum' variable has the UCHAR type. It
means that the condition will never hold.
11. Potential null pointer dereferencing
It is accepted to check pointers for being null pointers. But I know for sure that it is often done in a very
slapdash manner. That is, you do have a check, but it is useless. For example:
HRESULT CFileContext::GetNextSubscribedMessage()
{
....
m_pWdfRequest = pWdfRequest;
m_pWdfRequest->MarkCancelable(pCallbackCancel);
if (m_pWdfRequest != NULL)
{
CompleteOneArrivalEvent();
}
....
}
V595 The 'm_pWdfRequest' pointer was utilized before it was verified against nullptr. Check lines: 266,
267. filecontext.cpp 266
The 'm_pWdfRequest' pointer was used to call the MarkCancelable() function. And then the
programmer suddenly recalled that it might be a null pointer and made a check: "if (m_pWdfRequest !=
NULL)".
Such code usually appears during the refactoring process. Lines are moved and new expressions are
added. And it may happen that a pointer check is put below the place where the pointer is used for the
first time.
However, these errors don't affect the program execution in most cases. Pointers in these places simply
cannot equal zero, so the program works well. But I cannot say for sure whether or not these fragments
are buggy. It's up to the project's developers to figure it out.
Here is the list of the other fragments where this warning is generated:
• V595 The 'pAdapterCommon' pointer was utilized before it was verified against nullptr. Check
lines: 456, 477. adapter.cpp 456
• V595 The 'PortStream' pointer was utilized before it was verified against nullptr. Check lines:
111, 123. rtstream.cpp 111
• V595 The 'pncLock' pointer was utilized before it was verified against nullptr. Check lines: 85,
112. netcfgapi.cpp 85
• V595 The 'm_pInterruptSync' pointer was utilized before it was verified against nullptr. Check
lines: 707, 724. miniport.cpp 707
• V595 The 'deviceExtension' pointer was utilized before it was verified against nullptr. Check
lines: 798, 816. cdrom.c 798
12. • V595 The 'DeviceObject' pointer was utilized before it was verified against nullptr. Check lines:
9614, 9621. class.c 9614
• V595 The 'OffloadReadContext' pointer was utilized before it was verified against nullptr. Check
lines: 13704, 13706. class.c 13704
• V595 The 'device' pointer was utilized before it was verified against nullptr. Check lines: 206,
214. driver.cpp 206
• V595 The 'device' pointer was utilized before it was verified against nullptr. Check lines: 206,
214. driver.cpp 206
• V595 The 'instanceContext' pointer was utilized before it was verified against nullptr. Check
lines: 211, 237. support.c 211
• V595 The 'BiosCodeSpace' pointer was utilized before it was verified against nullptr. Check lines:
8229, 8249. lsi_u3.c 8229
• V595 The 'pAdapterCommon' pointer was utilized before it was verified against nullptr. Check
lines: 293, 319. adapter.cpp 293
• V595 The 'm_AdapterCommon' pointer was utilized before it was verified against nullptr. Check
lines: 217, 223. basetopo.cpp 217
• V595 The 'm_AdapterCommon' pointer was utilized before it was verified against nullptr. Check
lines: 200, 208. basewave.cpp 200
• V595 The 'port' pointer was utilized before it was verified against nullptr. Check lines: 216, 234.
common.cpp 216
• V595 The 'miniport' pointer was utilized before it was verified against nullptr. Check lines: 226,
239. common.cpp 226
• V595 The 'port' pointer was utilized before it was verified against nullptr. Check lines: 404, 412.
adapter.cpp 404
• V595 The 'm_AdapterCommon' pointer was utilized before it was verified against nullptr. Check
lines: 216, 222. basetopo.cpp 216
• V595 The 'targetPortGroupEntry' pointer was utilized before it was verified against nullptr.
Check lines: 534, 541. dsmmain.c 534
• V595 The 'dsmContext' pointer was utilized before it was verified against nullptr. Check lines:
364, 382. intrface.c 364
• V595 The 'passThrough' pointer was utilized before it was verified against nullptr. Check lines:
635, 648. utils.c 635
• V595 The 'passThrough' pointer was utilized before it was verified against nullptr. Check lines:
1537, 1550. utils.c 1537
• V595 The 'passThrough' pointer was utilized before it was verified against nullptr. Check lines:
1747, 1760. utils.c 1747
• V595 The 'ioStatus' pointer was utilized before it was verified against nullptr. Check lines: 5236,
5247. utils.c 5236
• V595 The 'devInfo' pointer was utilized before it was verified against nullptr. Check lines: 3227,
3229. wmi.c 3227
• V595 The 'pdi' pointer was utilized before it was verified against nullptr. Check lines: 575, 583.
codec.c 575
• V595 The 'AssocMgr' pointer was utilized before it was verified against nullptr. Check lines: 786,
789. ap_assocmgr.c 786
• V595 The 'newExtApPort' pointer was utilized before it was verified against nullptr. Check lines:
87, 101. ap_main.c 87
13. • V595 The 'ApPort' pointer was utilized before it was verified against nullptr. Check lines: 3068,
3070. ap_oids.c 3068
• V595 The 'HandleContext' pointer was utilized before it was verified against nullptr. Check lines:
2741, 2762. ncdirnotify.c 2741
• V595 The 'pHvl' pointer was utilized before it was verified against nullptr. Check lines: 277, 297.
hvl_main.c 277
• V595 The 'pNextActiveContext' pointer was utilized before it was verified against nullptr. Check
lines: 914, 916. hvl_main.c 914
• V595 The 'pNextActiveContext' pointer was utilized before it was verified against nullptr. Check
lines: 987, 989. hvl_main.c 987
• V595 The 'pNextCtx' pointer was utilized before it was verified against nullptr. Check lines: 874,
894. hvl_main.c 874
• V595 The 'pVNic' pointer was utilized before it was verified against nullptr. Check lines: 559,
584. vnic_main.c 559
• V595 The 'pExReq' pointer was utilized before it was verified against nullptr. Check lines: 1563,
1575. vnic_main.c 1563
• V595 The 'pJoinReq' pointer was utilized before it was verified against nullptr. Check lines: 241,
259. vnic_queue.c 241
• V595 The 'pChSwReq' pointer was utilized before it was verified against nullptr. Check lines: 439,
447. vnic_queue.c 439
• V595 The 'newPort' pointer was utilized before it was verified against nullptr. Check lines: 90,
100. base_port_main.c 90
• V595 The 'newPort' pointer was utilized before it was verified against nullptr. Check lines: 1379,
1390. helper_port_main.c 1379
• V595 The 'adapter' pointer was utilized before it was verified against nullptr. Check lines: 168,
196. mp_pnp.c 168
• V595 The 'newAdapter' pointer was utilized before it was verified against nullptr. Check lines:
458, 472. mp_pnp.c 458
• V595 The 'portRegInfo' pointer was utilized before it was verified against nullptr. Check lines:
153, 166. port_main.c 153
• V595 The 'newPort' pointer was utilized before it was verified against nullptr. Check lines: 268,
280. port_main.c 268
• V595 The 'pso24' pointer was utilized before it was verified against nullptr. Check lines: 338,
352. brush.c 338
• V595 The 'newHw' pointer was utilized before it was verified against nullptr. Check lines: 338,
358. hw_main.c 338
• V595 The 'Hw->Hal' pointer was utilized before it was verified against nullptr. Check lines: 605,
623. hw_main.c 605
• V595 The 'UseCoalesce' pointer was utilized before it was verified against nullptr. Check lines:
1760, 1781. hw_send.c 1760
• V595 The 'm_pWdfRequest' pointer was utilized before it was verified against nullptr. Check
lines: 248, 250. filecontext.cpp 248
• V595 The 'pDOMSnapshot' pointer was utilized before it was verified against nullptr. Check
lines: 711, 736. gdlsmpl.cpp 711
• V595 The '* ppDOMSnapshot' pointer was utilized before it was verified against nullptr. Check
lines: 833, 842. gdlsmpl.cpp 833
14. • V595 The 'm_pRootDocument' pointer was utilized before it was verified against nullptr. Check
lines: 163, 168. xmlhandler.cxx 163
• V595 The 'pNewNode' pointer was utilized before it was verified against nullptr. Check lines:
403, 411. xmlhandler.cxx 403
• V595 The 'pNewNode' pointer was utilized before it was verified against nullptr. Check lines:
625, 655. xmlhandler.cxx 625
• V595 The 'pNewAttribute' pointer was utilized before it was verified against nullptr. Check lines:
634, 646. xmlhandler.cxx 634
• V595 The 'pCurrentNode' pointer was utilized before it was verified against nullptr. Check lines:
883, 913. xmlhandler.cxx 883
• V595 The 'pAttribute' pointer was utilized before it was verified against nullptr. Check lines: 993,
1001. xmlhandler.cxx 993
• V595 The 'pAttrMap' pointer was utilized before it was verified against nullptr. Check lines: 982,
1011. xmlhandler.cxx 982
• V595 The 'pAttrNode' pointer was utilized before it was verified against nullptr. Check lines: 990,
1013. xmlhandler.cxx 990
• V595 The 'ppszDisplayName' pointer was utilized before it was verified against nullptr. Check
lines: 1734, 1752. features.cpp 1734
• V595 The 'ppszDisplayName' pointer was utilized before it was verified against nullptr. Check
lines: 1903, 1921. features.cpp 1903
• V595 The 'pszTemp' pointer was utilized before it was verified against nullptr. Check lines: 353,
366. util.c 353
• V595 The 'pszTimeout' pointer was utilized before it was verified against nullptr. Check lines:
713, 723. util.c 713
• V595 The 'device' pointer was utilized before it was verified against nullptr. Check lines: 193,
201. driver.cpp 193
• V595 The 'queue' pointer was utilized before it was verified against nullptr. Check lines: 70, 79.
queue.cpp 70
• V595 The 'device' pointer was utilized before it was verified against nullptr. Check lines: 206,
214. driver.cpp 206
• V595 The 'ctx' pointer was utilized before it was verified against nullptr. Check lines: 521, 545.
swapbuffers.c 521
• V595 The 'trimContext' pointer was utilized before it was verified against nullptr. Check lines:
2454, 2457. common.c 2454
• V595 The 'trimContext' pointer was utilized before it was verified against nullptr. Check lines:
2579, 2582. common.c 2579
• V595 The 'trimContext' pointer was utilized before it was verified against nullptr. Check lines:
2568, 2582. common.c 2568
• V595 The 'pWriteBuffer' pointer was utilized before it was verified against nullptr. Check lines:
682, 707. accelerometerdevice.cpp 682
• V595 The 'pBuffer' pointer was utilized before it was verified against nullptr. Check lines: 838,
867. accelerometerdevice.cpp 838
• V595 The 'pBuffer' pointer was utilized before it was verified against nullptr. Check lines: 928,
949. accelerometerdevice.cpp 928
• V595 The 'pBuffer' pointer was utilized before it was verified against nullptr. Check lines: 1017,
1030. accelerometerdevice.cpp 1017
15. • V595 The 'pWriteBuffer' pointer was utilized before it was verified against nullptr. Check lines:
1120, 1134. accelerometerdevice.cpp 1120
• V595 The 'pWriteBuffer' pointer was utilized before it was verified against nullptr. Check lines:
1291, 1305. accelerometerdevice.cpp 1291
• V595 The 'myDevice' pointer was utilized before it was verified against nullptr. Check lines: 193,
201. driver.cpp 193
• V595 The 'device' pointer was utilized before it was verified against nullptr. Check lines: 206,
214. driver.cpp 206
• V595 The 'deviceInterfaceDetailData' pointer was utilized before it was verified against nullptr.
Check lines: 170, 180. sensorcommunication.cpp 170
• V595 The 'device' pointer was utilized before it was verified against nullptr. Check lines: 199,
207. driver.cpp 199
• V595 The 'queue' pointer was utilized before it was verified against nullptr. Check lines: 119,
128. queue.cpp 119
• V595 The 'queue' pointer was utilized before it was verified against nullptr. Check lines: 1368,
1377. queue.cpp 1368
• V595 The 'device' pointer was utilized before it was verified against nullptr. Check lines: 206,
214. driver.cpp 206
• V595 The 'device' pointer was utilized before it was verified against nullptr. Check lines: 206,
214. driver.cpp 206
• V595 The 'device' pointer was utilized before it was verified against nullptr. Check lines: 223,
231. umdf_vdev_driver.cpp 223
• V595 The 'device' pointer was utilized before it was verified against nullptr. Check lines: 206,
214. driver.cpp 206
• V595 The 'device' pointer was utilized before it was verified against nullptr. Check lines: 206,
214. driver.cpp 206
• V595 The 'device' pointer was utilized before it was verified against nullptr. Check lines: 206,
214. driver.cpp 206
• V595 The 'packet' pointer was utilized before it was verified against nullptr. Check lines: 1305,
1312. inspect.c 1305
• V595 The 'FxRequest' pointer was utilized before it was verified against nullptr. Check lines: 937,
945. device.cpp 937
• V595 The 'pImageCodecInfo' pointer was utilized before it was verified against nullptr. Check
lines: 72, 83. gphelper.h 72
• V595 The 'pTargetBitmap' pointer was utilized before it was verified against nullptr. Check lines:
314, 329. gphelper.h 314
• V595 The 'pStreamOut' pointer was utilized before it was verified against nullptr. Check lines:
787, 790. imagefilter.cpp 787
• V595 The 'pWiaItemWrapper' pointer was utilized before it was verified against nullptr. Check
lines: 1590, 1620. imagefilter.cpp 1590
• V595 The 'pIWiaItemWrapper' pointer was utilized before it was verified against nullptr. Check
lines: 2028, 2032. imagefilter.cpp 2028
• V595 The 'pIWiaItemWrapper' pointer was utilized before it was verified against nullptr. Check
lines: 267, 282. segmentation.cpp 267
• V595 The 'm_pArray' pointer was utilized before it was verified against nullptr. Check lines: 193,
199. basicarray.h 193
16. • V595 The 'm_pArray' pointer was utilized before it was verified against nullptr. Check lines: 229,
235. basicarray.h 229
• V595 The 'pWIADeviceCapability' pointer was utilized before it was verified against nullptr.
Check lines: 233, 249. capman.cpp 233
• V595 The 'pImageCodecInfo' pointer was utilized before it was verified against nullptr. Check
lines: 298, 310. fileconv.cpp 298
• V595 The 'ppOutputStream' pointer was utilized before it was verified against nullptr. Check
lines: 413, 437. fileconv.cpp 413
• V595 The 'ppOutputStream' pointer was utilized before it was verified against nullptr. Check
lines: 713, 721. fileconv.cpp 713
• V595 The 'pwData' pointer was utilized before it was verified against nullptr. Check lines: 1966,
1996. scanjobs.cpp 1966
• V595 The 'm_pSensorManager' pointer was utilized before it was verified against nullptr. Check
lines: 4996, 5017. sensor.cpp 4996
• V595 The 'wszDataCopy' pointer was utilized before it was verified against nullptr. Check lines:
1320, 1334. basicddi.cpp 1320
• V595 The 'm_pOemCUIPParam' pointer was utilized before it was verified against nullptr. Check
lines: 490, 494. uictrl.cpp 490
• V595 The 'm_pOemCUIPParam' pointer was utilized before it was verified against nullptr. Check
lines: 807, 812. uictrl.cpp 807
• V595 The 'm_pOemCUIPParam' pointer was utilized before it was verified against nullptr. Check
lines: 1083, 1087. uictrl.cpp 1083
True null pointer dereferencing
We have just discussed potential null pointer dereferencing errors. Now let's examine the case when a
pointer is null for sure.
HRESULT CSensorDDI::OnGetDataFields(....)
{
....
if (nullptr != pSensor)
{
....
}
else
{
hr = E_POINTER;
Trace(TRACE_LEVEL_ERROR,
"pSensor == NULL before getting datafield %!GUID!-%i "
17. "value from %s, hr = %!HRESULT!",
&Key.fmtid, Key.pid, pSensor->m_SensorName, hr);
}
}
V522 Dereferencing of the null pointer 'pSensor' might take place. sensorddi.cpp 903
If the 'pSensor' pointer equals zero, you want to save the related information into the log. But it's
obviously a bad idea to try to take the name using "pSensor->m_SensorName".
A similar error can be found here:
V522 Dereferencing of the null pointer 'pSensor' might take place. sensorddi.cpp 1852
Strange loop
VOID ReportToString(
PHID_DATA pData,
_Inout_updates_bytes_(iBuffSize) LPSTR szBuff,
UINT iBuffSize
)
{
....
if(FAILED(StringCbPrintf (szBuff,
iBuffSize,
"Usage Page: 0x%x, Usages: ",
pData -> UsagePage)))
{
for(j=0; j<sizeof(szBuff); j++)
{
szBuff[j] = '0';
}
return;
}
....
18. }
V604 It is odd that the number of iterations in the loop equals to the size of the 'szBuff' pointer. hclient.c
1688
Note the "j<sizeof(szBuff)" loop's truncation condition. It is very strange that the loop is iterated the
same number of times as size of pointer (that is, 4 or 8). The following code should be most likely
written instead:
for(j=0; j<iBuffSize; j++)
A misprint making the code vulnerable
bool ParseNumber(....)
{
....
if ((*Value < Bounds.first) ||
(*Value > Bounds.second))
{
printf("Value %s is out of boundsn", String.c_str());
false;
}
....
}
V606 Ownerless token 'false'. util.cpp 91
It is checked that the variable's value is outside certain boundaries. This event must stop the function's
operation, but that doesn't happen. The programmer made a misprint writing "false" instead of "return
false;".
The same bug can be found here:
V606 Ownerless token 'false'. util.cpp 131
A misprint in switch
In the beginning of the article, I pointed out that errors taken from samples tend to spread all over. Now
I'll demonstrate it by an example. Take a look at this code.
PCHAR DbgDevicePowerString(IN WDF_POWER_DEVICE_STATE Type)
19. {
....
case WdfPowerDeviceD0:
return "WdfPowerDeviceD0";
case PowerDeviceD1:
return "WdfPowerDeviceD1";
case WdfPowerDeviceD2:
return "WdfPowerDeviceD2";
....
}
V556 The values of different enum types are compared: switch(ENUM_TYPE_A) { case ENUM_TYPE_B: ...
}. usb.c 450
Most likely, "case WdfPowerDeviceD1:" should be written instead of "case PowerDeviceD1:". And the
name 'PowerDeviceD1' refers to an absolutely different type which is enum type.
So, this error was found in several projects at once. It was multiplied thanks to Copy-Paste. These are
other fragments containing this bug:
• V556 The values of different enum types are compared: switch(ENUM_TYPE_A) { case
ENUM_TYPE_B: ... }. pcidrv.c 1707
• V556 The values of different enum types are compared: switch(ENUM_TYPE_A) { case
ENUM_TYPE_B: ... }. device.c 367
• V556 The values of different enum types are compared: switch(ENUM_TYPE_A) { case
ENUM_TYPE_B: ... }. device.c 935
• V556 The values of different enum types are compared: switch(ENUM_TYPE_A) { case
ENUM_TYPE_B: ... }. power.c 366
• V556 The values of different enum types are compared: switch(ENUM_TYPE_A) { case
ENUM_TYPE_B: ... }. power.c 56
• V556 The values of different enum types are compared: switch(ENUM_TYPE_A) { case
ENUM_TYPE_B: ... }. kmdf_vdev_pnp.c 727
Pi equals 3
NTSTATUS KcsAddTrignometricInstance (....)
{
....
Angle = (double)(Timestamp.QuadPart / 400000) *
20. (22/7) / 180;
....
}
V636 The '22 / 7' expression was implicitly casted from 'int' type to 'double' type. Consider utilizing an
explicit type cast to avoid the loss of a fractional part. An example: double A = (double)(X) / Y;. kcs.c 239
This is a strange integer division. Why not write 3 right away? Perhaps it would be better to write
(22.0/7). Then we'd get 3.1428.... By the way, Wikipedia prompts us that the fraction 22/7 is sometimes
used to get an approximate value of Pi. Well, then the programmer has got a VERY approximate value in
this sample.
Vestiges of the past
Long ago the 'new' operator used to return 0 if a memory allocation error occurred. Those times are
long gone. Now, according to the standard, the 'new' operator throws the std::bad_alloc() exception if
an error occurs. But many programmers either don't know or forget about this thing, or use their
ancient code still containing such checks.
No problem, one may say. Just an extra check, that's alright. Well, the point is that a program is usually
designed to perform some additional actions in case of an error. For instance it should release memory
or close a file. But now it throws an exception when there is not enough memory, and the code that
must handle it remains idle.
Have a look at this sample:
int SetHwidCallback(....)
{
....
LPTSTR * tmpArray = new LPTSTR[cnt+2];
if(!tmpArray) {
goto final;
}
....
final:
if(hwlist) {
DelMultiSz(hwlist);
}
return result;
}
21. V668 There is no sense in testing the 'tmpArray' pointer against null, as the memory was allocated using
the 'new' operator. The exception will be generated in the case of memory allocation error. cmds.cpp
2016
If the memory allocation error occurs, the program must move to the 'final' mark. After that, the
DelMultiSz() function must be called to delete something. That won't happen. An exception will be
generated which will leave the function. Even if this exception is correctly handled later, a memory leak
or some other bad thing will most likely happen.
In Windows 8 Driver Samples, there are a lot of fragments where a pointer received from the 'new'
operator is checked for being null. In most cases, everything should work well. But the programmers still
need to investigate these fragments more thoroughly. Here they are:
• V668 There is no sense in testing the 'pINotifyDataObject' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. acallback.cpp 309
• V668 There is no sense in testing the 'pIAsynchCallback' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. client.cpp 142
• V668 There is no sense in testing the 'pINotifyDataObject' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. acallback.cpp 226
• V668 There is no sense in testing the 'pIAsynchCallback' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. asyncnotify.cpp 57
• V668 There is no sense in testing the 'pClientNotification' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. asyncnotify.cpp 77
• V668 There is no sense in testing the 'pIAsynchCallback' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. asyncnotify.cpp 102
• V668 There is no sense in testing the 'pClientNotification' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. asyncnotify.cpp 120
• V668 There is no sense in testing the 'pNewItem' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. tlist.h 129
• V668 There is no sense in testing the 'pNewItem' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. tlist.h 158
• V668 There is no sense in testing the 'pNewItem' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. tlist.h 384
• V668 There is no sense in testing the 'pNewItem' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. tlist.h 414
22. • V668 There is no sense in testing the 'pAudioParamsCopy' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. advendpointproppage.cpp 1004
• V668 There is no sense in testing the 'pAudioFXParamsCopy' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. swapproppage.cpp 811
• V668 There is no sense in testing the 'array' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. devcon.cpp 389
• V668 There is no sense in testing the 'multiSz' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. devcon.cpp 434
• V668 There is no sense in testing the 'resDesData' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. dump.cpp 250
• V668 There is no sense in testing the 'lpszMsgBuf' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. debug.cpp 128
• V668 There is no sense in testing the 'lpszMsgBuf' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. debug.cpp 185
• V668 There is no sense in testing the 'pOemCB' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. oemcom.cpp 448
• V668 There is no sense in testing the 'pFontCF' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. oemcom.cpp 522
• V668 There is no sense in testing the 'lpszMsgBuf' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. debug.cpp 128
• V668 There is no sense in testing the 'lpszMsgBuf' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. debug.cpp 185
• V668 There is no sense in testing the 'pOemCB' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. oemcom.cpp 826
• V668 There is no sense in testing the 'pFontCF' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. oemcom.cpp 903
• V668 There is no sense in testing the 'queue' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. controlqueue.cpp 104
• V668 There is no sense in testing the 'queue' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. readwritequeue.cpp 203
23. • V668 There is no sense in testing the 'device' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. device.cpp 65
• V668 There is no sense in testing the 'instanceId' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. device.cpp 415
• V668 There is no sense in testing the 'm_Ppd' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. device.cpp 626
• V668 There is no sense in testing the 'factory' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. dllsup.cpp 183
• V668 There is no sense in testing the 'driver' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. driver.cpp 54
• V668 There is no sense in testing the 'buffer' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. socketechoserver.cpp 59
• V668 There is no sense in testing the 'client' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. socketechoserver.cpp 383
• V668 There is no sense in testing the 'device' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. device.cpp 63
• V668 There is no sense in testing the 'factory' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. dllsup.cpp 157
• V668 There is no sense in testing the 'driver' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. driver.cpp 54
• V668 There is no sense in testing the 'pMyQueue' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. queue.cpp 90
• V668 There is no sense in testing the 'pContext' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. device.cpp 343
• V668 There is no sense in testing the 'pConnection' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. queue.cpp 208
• V668 There is no sense in testing the 'm_Luminous' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. sauron.cpp 66
• V668 There is no sense in testing the 'pwszBuffer' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. ihvsampleextui.cpp 633
24. • V668 There is no sense in testing the 'pOemPDEV' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 730
• V668 There is no sense in testing the 'pOemCP' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 1795
• V668 There is no sense in testing the 'pFontCF' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 1880
• V668 There is no sense in testing the 'm_pbPayload' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. filecontext.h 48
• V668 There is no sense in testing the 'm_pszType' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. filecontext.cpp 136
• V668 There is no sense in testing the 'pbNewPayload' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. filecontext.cpp 596
• V668 There is no sense in testing the 'pMyPayload' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. filecontext.cpp 627
• V668 There is no sense in testing the 'pConnection' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. connection.cpp 46
• V668 There is no sense in testing the 'pMessage' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. connection.cpp 251
• V668 There is no sense in testing the 'pContext' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. queue.cpp 207
• V668 There is no sense in testing the 'pszFileNameBuffer' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. queue.cpp 226
• V668 There is no sense in testing the 'pMessage' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. queue.cpp 571
• V668 There is no sense in testing the 'pMessage' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. queue.cpp 705
• V668 There is no sense in testing the 'pGDLSampleClassFactory' pointer against null, as the
memory was allocated using the 'new' operator. The exception will be generated in the case of
memory allocation error. gdlsmpl.cpp 255
• V668 There is no sense in testing the 'pOemCB' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. gdlsmpl.cpp 380
25. • V668 There is no sense in testing the 'lpszMsgBuf' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. debug.cpp 114
• V668 There is no sense in testing the 'pOemPDEV' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 732
• V668 There is no sense in testing the 'pOemCP' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 1717
• V668 There is no sense in testing the 'pFontCF' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 1807
• V668 There is no sense in testing the 'poempdev' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 329
• V668 There is no sense in testing the 'pOemCP' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 529
• V668 There is no sense in testing the 'pFontCF' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 621
• V668 There is no sense in testing the 'pOemCB' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 474
• V668 There is no sense in testing the 'pFontCF' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 556
• V668 There is no sense in testing the 'pOemPDEV' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 711
• V668 There is no sense in testing the 'pOemCP' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 1690
• V668 There is no sense in testing the 'pFontCF' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 1784
• V668 There is no sense in testing the 'pOemCB' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 472
• V668 There is no sense in testing the 'pFontCF' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 551
• V668 There is no sense in testing the 'pOemCB' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cxx 386
26. • V668 There is no sense in testing the 'pOemPT' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cxx 401
• V668 There is no sense in testing the 'pFontCF' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cxx 483
• V668 There is no sense in testing the 'lpszMsgBuf' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. debug.cpp 115
• V668 There is no sense in testing the 'lpszMsgBuf' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. debug.cpp 175
• V668 There is no sense in testing the 'pOemCB' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 519
• V668 There is no sense in testing the 'pFontCF' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 601
• V668 There is no sense in testing the 'pszAngle' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. command.cpp 290
• V668 There is no sense in testing the 'pOemCP' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 396
• V668 There is no sense in testing the 'pFontCF' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 481
• V668 There is no sense in testing the 'pOemCB' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 429
• V668 There is no sense in testing the 'pFontCF' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 511
• V668 There is no sense in testing the 'lpszMsgBuf' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. debug.cpp 115
• V668 There is no sense in testing the 'lpszMsgBuf' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. debug.cpp 175
• V668 There is no sense in testing the 'm_pData' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. features.cpp 234
• V668 There is no sense in testing the 'm_pFeatures' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. features.cpp 984
27. • V668 There is no sense in testing the 'pPairs' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. features.cpp 1564
• V668 There is no sense in testing the 'pUIReplacementCF' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 162
• V668 There is no sense in testing the 'pOemCB' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 292
• V668 There is no sense in testing the 'pOemCB' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 482
• V668 There is no sense in testing the 'pFontCF' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 564
• V668 There is no sense in testing the 'p2' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. pixel.cpp 585
• V668 There is no sense in testing the 'pOemCB' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 431
• V668 There is no sense in testing the 'pFontCF' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 513
• V668 There is no sense in testing the 'poempdev' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 311
• V668 There is no sense in testing the 'pOemCP' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 854
• V668 There is no sense in testing the 'pFontCF' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 939
• V668 There is no sense in testing the 'Contexts' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. plx.cpp 442
• V668 There is no sense in testing the 'Threads' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. plx.cpp 442
• V668 There is no sense in testing the 'lpszMsgBuf' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. debug.cpp 115
• V668 There is no sense in testing the 'lpszMsgBuf' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. debug.cpp 175
28. • V668 There is no sense in testing the 'pOemCB' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 616
• V668 There is no sense in testing the 'pFontCF' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. intrface.cpp 698
• V668 There is no sense in testing the 'pReadBuf' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. streamfilter.cxx 224
• V668 There is no sense in testing the 'device' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. device.cpp 57
• V668 There is no sense in testing the 'factory' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. dllsup.cpp 163
• V668 There is no sense in testing the 'driver' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. driver.cpp 54
• V668 There is no sense in testing the 'queue' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. queue.cpp 59
• V668 There is no sense in testing the 'queue' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. controlqueue.cpp 104
• V668 There is no sense in testing the 'queue' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. readwritequeue.cpp 204
• V668 There is no sense in testing the 'device' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. device.cpp 67
• V668 There is no sense in testing the 'deviceName' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. device.cpp 470
• V668 There is no sense in testing the 'factory' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. dllsup.cpp 183
• V668 There is no sense in testing the 'driver' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. driver.cpp 54
• V668 There is no sense in testing the 'pGeolocation' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. sensormanager.cpp 395
• V668 There is no sense in testing the 'm_pDataBuffer' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. accelerometerdevice.cpp 531
29. • V668 There is no sense in testing the 'pWriteBuffer' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. accelerometerdevice.cpp 646
• V668 There is no sense in testing the 'pReadBuffer' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. accelerometerdevice.cpp 646
• V668 There is no sense in testing the 'pBuffer' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. accelerometerdevice.cpp 792
• V668 There is no sense in testing the 'pBuffer' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. accelerometerdevice.cpp 899
• V668 There is no sense in testing the 'pBuffer' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. accelerometerdevice.cpp 981
• V668 There is no sense in testing the 'pWriteBuffer' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. accelerometerdevice.cpp 1073
• V668 There is no sense in testing the 'pWriteBuffer' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. accelerometerdevice.cpp 1243
• V668 There is no sense in testing the 'pBuffer' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. accelerometerdevice.cpp 2009
• V668 There is no sense in testing the 'myDevice' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. device.cpp 60
• V668 There is no sense in testing the 'factory' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. dllsup.cpp 155
• V668 There is no sense in testing the 'myDriver' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. driver.cpp 54
• V668 There is no sense in testing the 'myRemoteTarget' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. remotetarget.cpp 72
• V668 There is no sense in testing the 'pMyDevice' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. device.h 47
• V668 There is no sense in testing the 'pMyQueue' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. queue.h 46
• V668 There is no sense in testing the 'deviceName' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. device.cpp 174
30. • V668 There is no sense in testing the 'device' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. device.cpp 61
• V668 There is no sense in testing the 'factory' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. dllsup.cpp 158
• V668 There is no sense in testing the 'driver' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. driver.cpp 54
• V668 There is no sense in testing the '_pSensorManagerEvents' pointer against null, as the
memory was allocated using the 'new' operator. The exception will be generated in the case of
memory allocation error. sampleradiomanager.cpp 39
• V668 There is no sense in testing the 'device' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. device.cpp 59
• V668 There is no sense in testing the 'factory' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. dllsup.cpp 165
• V668 There is no sense in testing the 'driver' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. driver.cpp 59
• V668 There is no sense in testing the 'queue' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. queue.cpp 108
• V668 There is no sense in testing the 'queue' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. queue.cpp 1358
• V668 There is no sense in testing the 'device' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. device.cpp 61
• V668 There is no sense in testing the 'devInstId' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. device.cpp 547
• V668 There is no sense in testing the 'pdoName' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. device.cpp 622
• V668 There is no sense in testing the 'factory' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. dllsup.cpp 158
• V668 There is no sense in testing the 'driver' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. driver.cpp 54
• V668 There is no sense in testing the 'pMyQueue' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. queue.cpp 85
31. • V668 There is no sense in testing the 'buffer' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. ringbuffer.cpp 43
• V668 There is no sense in testing the 'device' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. device.cpp 65
• V668 There is no sense in testing the 'factory' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. dllsup.cpp 183
• V668 There is no sense in testing the 'driver' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. driver.cpp 54
• V668 There is no sense in testing the 'vDevice' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. umdf_vdev_device.cpp 69
• V668 There is no sense in testing the 'factory' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. umdf_vdev_dll.cpp 181
• V668 There is no sense in testing the 'driver' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. umdf_vdev_driver.cpp 67
• V668 There is no sense in testing the 'queue' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. umdf_vdev_parallelqueue.cpp 124
• V668 There is no sense in testing the 'queue' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. umdf_vdev_sequentialqueue.cpp 111
• V668 There is no sense in testing the 'device' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. device.cpp 69
• V668 There is no sense in testing the 'deviceName' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. device.cpp 315
• V668 There is no sense in testing the 'factory' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. dllsup.cpp 183
• V668 There is no sense in testing the 'driver' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. driver.cpp 54
• V668 There is no sense in testing the 'queue' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. controlqueue.cpp 104
• V668 There is no sense in testing the 'device' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. device.cpp 69
32. • V668 There is no sense in testing the 'deviceName' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. device.cpp 338
• V668 There is no sense in testing the 'factory' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. dllsup.cpp 183
• V668 There is no sense in testing the 'driver' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. driver.cpp 54
• V668 There is no sense in testing the 'queue' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. controlqueue.cpp 104
• V668 There is no sense in testing the 'queue' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. readwritequeue.cpp 204
• V668 There is no sense in testing the 'device' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. device.cpp 69
• V668 There is no sense in testing the 'deviceName' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. device.cpp 352
• V668 There is no sense in testing the 'factory' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. dllsup.cpp 183
• V668 There is no sense in testing the 'driver' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. driver.cpp 54
• V668 There is no sense in testing the 'pTargetBitmap' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. imagefilter.cpp 209
• V668 There is no sense in testing the 'pWiaItemWrapper' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. imagefilter.cpp 1482
• V668 There is no sense in testing the 'pIWiaItemWrapper' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. imagefilter.cpp 1968
• V668 There is no sense in testing the 'm_pCurrentStream' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. imagefilter.cpp 2049
• V668 There is no sense in testing the 'pImageFilter' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. imagefilter.cpp 2181
• V668 There is no sense in testing the 'pIWiaItemWrapper' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. segmentation.cpp 205
33. • V668 There is no sense in testing the 'pSegFilter' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. segmentation.cpp 429
• V668 There is no sense in testing the 'pResult' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. basicstr.h 963
• V668 There is no sense in testing the 'pTmpArray' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. basicarray.h 139
• V668 There is no sense in testing the 'pTmpArray' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. basicarray.h 186
• V668 There is no sense in testing the 'm_pBitmapData' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wiadevice.h 65
• V668 There is no sense in testing the 'm_pFormats' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wiadriver.cpp 2425
• V668 There is no sense in testing the 'pDev' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. wiadriver.cpp 2615
• V668 There is no sense in testing the 'pcf' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. wiadriver.cpp 2673
• V668 There is no sense in testing the 'pInfo' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. wiapropertymanager.cpp 176
• V668 There is no sense in testing the 'pguid' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. wiapropertymanager.cpp 778
• V668 There is no sense in testing the 'pTmpArray' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. basicarray.h 171
• V668 There is no sense in testing the 'pTmpArray' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. basicarray.h 222
• V668 There is no sense in testing the 'pImageCodecInfo' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. fileconv.cpp 271
• V668 There is no sense in testing the 'pInfo' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. propman.cpp 185
• V668 There is no sense in testing the 'pguid' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. propman.cpp 1140
34. • V668 There is no sense in testing the 'pwData' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. scanjobs.cpp 1905
• V668 There is no sense in testing the 'pWpdBaseDriver' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. driver.cpp 45
• V668 There is no sense in testing the 'pClientContextMap' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. queue.cpp 209
• V668 There is no sense in testing the 'pEnumeratorContext' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wpdobjectenum.cpp 105
• V668 There is no sense in testing the 'pResourceContext' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wpdobjectresources.cpp 291
• V668 There is no sense in testing the 'pWpdBaseDriver' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. driver.cpp 45
• V668 There is no sense in testing the 'pClientContextMap' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. queue.cpp 290
• V668 There is no sense in testing the 'pEnumeratorContext' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wpdobjectenum.cpp 105
• V668 There is no sense in testing the 'pResourceContext' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wpdobjectresources.cpp 291
• V668 There is no sense in testing the 'pWpdBaseDriver' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. driver.cpp 48
• V668 There is no sense in testing the 'pClientContextMap' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. queue.cpp 211
• V668 There is no sense in testing the 'pEnumeratorContext' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wpdobjectenum.cpp 112
• V668 There is no sense in testing the 'pszMsgBuf' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. debug.cpp 72
• V668 There is no sense in testing the 'pFilter' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. clasfact.h 75
• V668 There is no sense in testing the 'pFactory' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. clasfact.h 158
35. • V668 There is no sense in testing the 'pRecvReport' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. sensor.cpp 2320
• V668 There is no sense in testing the 'pRecvReport' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. sensor.cpp 2976
• V668 There is no sense in testing the 'pSendReport' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. sensorddi.cpp 530
• V668 There is no sense in testing the 'pWpdBaseDriver' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. driver.cpp 52
• V668 There is no sense in testing the 'pVIC' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. fakecontactsservicecontent.cpp 436
• V668 There is no sense in testing the 'pClientContextMap' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. queue.cpp 287
• V668 There is no sense in testing the 'pContext' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wpdbasedriver.cpp 341
• V668 There is no sense in testing the 'pEnumeratorContext' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wpdobjectenum.cpp 122
• V668 There is no sense in testing the 'pContext' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wpdobjectpropertiesbulk.cpp 931
• V668 There is no sense in testing the 'pContext' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wpdobjectpropertiesbulk.cpp 1028
• V668 There is no sense in testing the 'pResourceContext' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wpdobjectresources.cpp 276
• V668 There is no sense in testing the 'm_pTask' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wpdservicemethods.cpp 61
• V668 There is no sense in testing the 'pContext' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wpdservicemethods.cpp 295
• V668 There is no sense in testing the 'pContent' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. fakedevice.h 1927
• V668 There is no sense in testing the 'pContent' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. fakedevice.h 1970
36. • V668 There is no sense in testing the 'pContent' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. fakedevice.h 2044
• V668 There is no sense in testing the 'pContent' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. fakedevice.h 2072
• V668 There is no sense in testing the 'pContent' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. fakedevice.h 2100
• V668 There is no sense in testing the 'pContent' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. fakedevice.h 2128
• V668 There is no sense in testing the 'pContent' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. fakedevice.h 2182
• V668 There is no sense in testing the 'pContent' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. fakedevice.h 2211
• V668 There is no sense in testing the 'pszDeviceName' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. device.cpp 136
• V668 There is no sense in testing the 'pWpdBaseDriver' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. driver.cpp 52
• V668 There is no sense in testing the 'pClientContextMap' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. queue.cpp 208
• V668 There is no sense in testing the 'pContext' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wpdbasedriver.cpp 286
• V668 There is no sense in testing the 'pContext' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wpdobjectenum.cpp 283
• V668 There is no sense in testing the 'pContext' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wpdobjectmanagement.cpp 1026
• V668 There is no sense in testing the 'pContext' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wpdobjectpropertiesbulk.cpp 886
• V668 There is no sense in testing the 'pContext' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wpdobjectpropertiesbulk.cpp 986
• V668 There is no sense in testing the 'pContext' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wpdobjectresources.cpp 895
37. • V668 There is no sense in testing the 'm_pNUpPage' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. nupflt.cpp 428
• V668 There is no sense in testing the 'm_pNUpProps' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. nuppage.cpp 82
• V668 There is no sense in testing the 'm_pNUpTransform' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. nuppage.cpp 86
• V668 There is no sense in testing the 'm_pNUpProps' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. nuppage.cpp 366
• V668 There is no sense in testing the 'm_pNUpTransform' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. nuppage.cpp 370
• V668 There is no sense in testing the 'm_pMultiByte' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. widetoutf8.cpp 136
• V668 There is no sense in testing the 'pXpsProcessor' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. xdstrmflt.cpp 127
• V668 There is no sense in testing the 'pBuff' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. xdstrmflt.cpp 157
• V668 There is no sense in testing the 'szFileName' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. xpsarch.cpp 80
• V668 There is no sense in testing the 'pXpsWriteFile' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. xpsproc.cpp 876
• V668 There is no sense in testing the 'pBuff' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. cmimg.cpp 364
• V668 There is no sense in testing the 'pBuffer' pointer against null, as the memory was allocated
using the 'new' operator. The exception will be generated in the case of memory allocation
error. cmimg.cpp 640
• V668 There is no sense in testing the 'pProfileData' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. profile.cpp 156
• V668 There is no sense in testing the 'm_phProfiles' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. transform.cpp 189
• V668 There is no sense in testing the 'm_pcstrProfileKeys' pointer against null, as the memory
was allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. transform.cpp 519
38. • V668 There is no sense in testing the 'm_pScanBuffer' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wictobmscn.cpp 708
• V668 There is no sense in testing the 'pFontData' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wmfont.cpp 159
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. colppg.cpp 62
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. colppg.cpp 70
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. colppg.cpp 79
• V668 There is no sense in testing the 'pXDSmplUICF' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. dllentry.cpp 154
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. ftrppg.cpp 62
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. ftrppg.cpp 70
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. ftrppg.cpp 79
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. ftrppg.cpp 83
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. ftrppg.cpp 93
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. ftrppg.cpp 97
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. ftrppg.cpp 107
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. ftrppg.cpp 111
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. ftrppg.cpp 121
39. • V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. ftrppg.cpp 125
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. ftrppg.cpp 135
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. ftrppg.cpp 144
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. ftrppg.cpp 153
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. ftrppg.cpp 162
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. ftrppg.cpp 171
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. ftrppg.cpp 180
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. ftrppg.cpp 189
• V668 There is no sense in testing the 'lpBuffer' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. uictrl.cpp 1851
• V668 There is no sense in testing the 'lpBuffer' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. uictrl.cpp 1960
• V668 There is no sense in testing the 'lpOrgBuffer' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. uictrl.cpp 1970
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wmppg.cpp 63
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wmppg.cpp 71
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wmppg.cpp 80
• V668 There is no sense in testing the 'pControl' pointer against null, as the memory was
allocated using the 'new' operator. The exception will be generated in the case of memory
allocation error. wmppg.cpp 89