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:

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; .... }

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); .... }

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

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) { 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; } .... }

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 ); 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> #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

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.

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

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

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

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

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

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 " "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; } .... }

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 bounds

", 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) { .... 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) * (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; }

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 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. wmppg.cpp 103

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 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. wmppg.cpp 117

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 121

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 131

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 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. wmppg.cpp 145

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 149

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 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. wmppg.cpp 163

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 173

V668 There is no sense