How do I get the version of a driver on Windows from C++ - c++

I'm looking for a programmatic way to get the version number of a driver. I want the same number that device manager shows in the driver properties for a device.
Background: I have an application that talks to some custom hardware. The device driver for the custom hardware has known bugs before a certain version number. I want the application to check the driver version and warn the user if they need to update it. The application runs on Windows XP and 7 and is written in C++.
A previous hack I used was to read the .sys file directly from system32/drivers and search for "FileVersion" directly. This is bad for many reasons. In particular it seems to need admin privileges on Windows 7.
I know the class GUID and the hardware ID (ie "USB\VID_1234&PID_5678").
The application currently uses SetupDiGetClassDevs, SetupDiEnumDeviceInterfaces and then SetupDiGetDeviceInterfaceDetail to get the "DevicePath". It then calls CreateFile with that path to talk to the driver.
It looks like I need to get a SP_DRVINFO_DATA structure from somewhere. I've tried various functions from setupapi.h, such as SetupDiGetDeviceInterfaceDetail. Here's some code I've tried that fails:
int main(void)
{
HDEVINFO DeviceInfoSet = SetupDiGetClassDevs((LPGUID)&GUID_DEVINTERFACE_USBSPI, NULL, NULL,
DIGCF_PRESENT | DIGCF_DEVICEINTERFACE);
SP_INTERFACE_DEVICE_DATA InterfaceDeviceData;
InterfaceDeviceData.cbSize = sizeof(SP_INTERFACE_DEVICE_DATA);
// Cycle through all devices.
for (int i = 0; i < 32; i++)
{
if (!SetupDiEnumDeviceInterfaces(DeviceInfoSet, 0, (LPGUID)&GUID_DEVINTERFACE_USBSPI, i, &InterfaceDeviceData))
break;
PSP_DEVICE_INTERFACE_DETAIL_DATA DeviceInterfaceDetailData;
DWORD RequiredSize;
SetupDiGetDeviceInterfaceDetail(DeviceInfoSet, &InterfaceDeviceData, NULL, 0, &RequiredSize, NULL);
DeviceInterfaceDetailData = (PSP_DEVICE_INTERFACE_DETAIL_DATA)HeapAlloc(GetProcessHeap(), HEAP_GENERATE_EXCEPTIONS | HEAP_ZERO_MEMORY, RequiredSize);
try
{
DeviceInterfaceDetailData->cbSize = sizeof(SP_DEVICE_INTERFACE_DETAIL_DATA);
SetupDiGetDeviceInterfaceDetail(DeviceInfoSet, &InterfaceDeviceData, DeviceInterfaceDetailData, RequiredSize, NULL, NULL);
// Try to get the driver info. This part always fails with code
// 259 (ERROR_NO_MORE_ITEMS).
SP_DRVINFO_DATA drvInfo;
drvInfo.cbSize = sizeof(SP_DRVINFO_DATA);
if (!SetupDiEnumDriverInfo(DeviceInfoSet, NULL, SPDIT_CLASSDRIVER, i, &drvInfo))
printf("error = %d\n", GetLastError());
printf("Driver version is %08x %08x\n", drvInfo.DriverVersion >> 32, drvInfo.DriverVersion & 0xffffffff);
}
catch(...)
{
HeapFree(GetProcessHeap(), 0, DeviceInterfaceDetailData);
throw;
}
HeapFree(GetProcessHeap(), 0, DeviceInterfaceDetailData);
}
SetupDiDestroyDeviceInfoList(DeviceInfoSet);
return 0;
}
Edit - My updated code now looks like this:
HDEVINFO devInfoSet = SetupDiGetClassDevs(&GUID_DEVINTERFACE_USBSPI, NULL, NULL,
DIGCF_PRESENT | DIGCF_DEVICEINTERFACE);
// Cycle through all devices.
for (int i = 0; ; i++)
{
// Get the device info for this device
SP_DEVINFO_DATA devInfo;
devInfo.cbSize = sizeof(SP_DEVINFO_DATA);
if (!SetupDiEnumDeviceInfo(devInfoSet, i, &devInfo))
break;
// Get the first info item for this driver
SP_DRVINFO_DATA drvInfo;
drvInfo.cbSize = sizeof(SP_DRVINFO_DATA);
if (!SetupDiEnumDriverInfo(devInfoSet, &devInfo, SPDIT_COMPATDRIVER, 0, &drvInfo))
printf("err - %d\n", GetLastError()); // Still fails with "no more items"
}
SetupDiDestroyDeviceInfoList(devInfoSet);

You're incorrectly reusing i as index in SetupDiEnumDriverInfo. That should be an inner loop for each driver info element per driver. As a result, you fail to retrieve driver info #0 for device #1.
Still, that doesn't explain why info #0 for device #0 fails. For that, you have to look at the second parameter of SetupDiEnumDriverInfo. That is a SP_DEVINFO_DATA structure for your device, but you leave it set to NULL. That gets you the list of drivers associated with the device class, not the device. I.e. that works for mice and USB sticks, which have class drivers. Your device probably has a vendor-specific driver, so you need the driver for that specific device.

As you asked a nearly identical question I post only the link to my answer here:
Why does SetupDiEnumDriverInfo give two version numbers for my driver

Related

Calling WDF driver from c++

I've been trying to call a sample driver. I have written DriverEntry method, where I initialize both the driver name and symbolic ling pointing to the driver.
// UNICODE_STRING DriverName, SymbolName; // Driver registry paths
...
// Driver Entrypoint
NTSTATUS
DriverEntry(PDRIVER_OBJECT pDriverObject, PUNICODE_STRING pRegistryPath) {
Q_UNUSED(pRegistryPath);
DbgPrintEx(0, 0, "Driver Loaded\n");
// The PsSetLoadImageNotifyRoutine routine registers a driver-supplied
// callback that is subsequently notified whenever
// an image is loaded (or mapped into memory).
PsSetLoadImageNotifyRoutine(ImageLoadCallback);
// initialize driver name
RtlInitUnicodeString(&DriverName, L"\\Device\\Explorer");
// initialize symbolic link
RtlInitUnicodeString(&SymbolName, L"\\DosDevices\\Explorer");
IoCreateDevice(pDriverObject, 0, &SymbolName, FILE_DEVICE_UNKNOWN,
FILE_DEVICE_SECURE_OPEN, FALSE, &pDeviceObject);
IoCreateSymbolicLink(&DriverName, &SymbolName);
pDriverObject->MajorFunction[IRP_MJ_CREATE] = CreateCall;
pDriverObject->MajorFunction[IRP_MJ_CLOSE] = CloseCall;
pDriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = IoControl;
pDriverObject->DriverUnload = UnloadDriver;
pDeviceObject->Flags |= DO_DIRECT_IO;
pDeviceObject->Flags &= ~DO_DEVICE_INITIALIZING;
return STATUS_SUCCESS;
}
When I load the driver up (using OSR Driver Loader, could be done using cmd also, by registering the driver as a new service), I get expected output in DebugView (sysinternals tool allowing to see kernel debug logs)
Now I needed to make sure that both the device and symlink are present in Windows Object Directories. To do that, I use WinObj (another tool from sysinternals), here is the output
What confuses me here, is that the symbolic link is in Device folder, instead of GLOBAL??.
Symbolic link in Device
Device in GLOBAL??
Now, finally, calling the driver itself. I use c++ for that purpose and this is my code,
class Test
{
public:
HANDLE hDriver; // Handle to driver
// Initializer
Test::Test(LPCSTR RegistryPath)
{
LPCSTR path = "\\\\.\\Explorer";
hDriver = CreateFileA(path, GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE, 0, OPEN_EXISTING, 0, 0);
if (hDriver == INVALID_HANDLE_VALUE)
{
// Handle the error.
char result = GetLastError();
bool zadek = false;
}
}
The problem is that I can't get a valid handle for the driver. The value of hDriver is always either 0x00000000000000a0 or 0xffffffff, no matter the path I use. I'm using createFileA because I want to access system memory.
Is there some blatant mistake I made?
I should say it is over 8-9 year since last time I written a device driver, but what comes off the top of my head are:
You say you get 0xa0 for hDriver which is a valid handle value.
Right now, you can only use device IO control, because you only have callback for IRP_MJ_DEVICE_CONTROL.
Try L"\\??\\Explorer" or L"\\GLOBAL??\\Explorer" for symbolic link.
You need to use DriverName for IoCreateDevice.
You are passing incorrect arguments to IoCreateSymbolicLink.
So your code should become like this:
...
// initialize driver name
RtlInitUnicodeString(&DriverName, L"\\Device\\Explorer");
// initialize symbolic link
RtlInitUnicodeString(&SymbolName, L"\\??\\Explorer");
IoCreateDevice(pDriverObject, 0, &DriverName, FILE_DEVICE_UNKNOWN,
FILE_DEVICE_SECURE_OPEN, FALSE, &pDeviceObject);
IoCreateSymbolicLink(&SymbolName, &DriverName);
...

How do I get the friendly name of a USB device in Windows?

I'm trying to get the "friendly name" of a plugged-in USB device. I'm using SetupDiGetDeviceRegistryProperty method with SPDRP_FRIENDLYNAME property but the method returns false and sets the error code to ERROR_INVALID_DATA, although everything works fine with other properties, such as SPDRP_DEVICEDESC or SPDRP_MFG.
I checked the registry and the Device Manager and the friendly name exists.
Does anyone have any idea?
UPDATE: What i tried so far:
GUID hidGuid;
HidD_GetHidGuid(&hidGuid);
HDEVINFO hDevInfo = SetupDiGetClassDevs(&hidGuid, 0, 0, DIGCF_PRESENT | DIGCF_INTERFACEDEVICE);
if (INVALID_HANDLE_VALUE == hDevInfo)
{
AfxMessageBox(CString("SetupDiGetClassDevs(): ")
+ _com_error(GetLastError()).ErrorMessage(), MB_ICONEXCLAMATION);
return;
}
SP_DEVINFO_DATA* pspDevInfoData =
(SP_DEVINFO_DATA*)HeapAlloc(GetProcessHeap(), 0, sizeof(SP_DEVINFO_DATA));
pspDevInfoData->cbSize = sizeof(SP_DEVINFO_DATA);
for (int i = 0; SetupDiEnumDeviceInfo(hDevInfo, i, pspDevInfoData); i++)
{
DWORD DataT;
DWORD nSize = 0;
TCHAR buf[MAX_PATH];
if (!SetupDiGetDeviceInstanceId(hDevInfo, pspDevInfoData, buf, sizeof(buf), &nSize))
{
AfxMessageBox(CString("SetupDiGetDeviceInstanceId(): ")
+ _com_error(GetLastError()).ErrorMessage(), MB_ICONEXCLAMATION);
break;
}
if (SetupDiGetDeviceRegistryProperty(hDevInfo, pspDevInfoData,
SPDRP_FRIENDLYNAME, &DataT, (PBYTE)buf, sizeof(buf), &nSize))
{
//display buf
}
else
{
if (GetLastError() == ERROR_INVALID_DATA)
{
//display ERROR_INVALID_DATA
}
if (SetupDiGetDeviceRegistryProperty(hDevInfo, pspDevInfoData, SPDRP_MFG, &DataT, (PBYTE)buf, sizeof(buf), &nSize))
{
//display buf
}
if (SetupDiGetDeviceRegistryProperty(hDevInfo, pspDevInfoData,
SPDRP_DEVICEDESC, &DataT, (PBYTE)buf, sizeof(buf), &nSize))
{
// display buf
}
}
}
Something like this. As i said, i get the device description and the device manufacturer, but not the friendly name.
Not all devices have SPDRP_FRIENDLYNAME attribute set. When that's the case, ERROR_INVALID_DATA is expected, it tells you just that.
When they don’t have it, device manager GUI uses another one for display name, SPDRP_DEVICEDESC
Maybe useful information:
In my case I had two network adapters, but the function succeeded only for the adapter that is shown as "... #2" in device manager when SPDRP_FRIENDLYNAME is used.
I could also verify that the other adapter (without the "... #2") does not have a value "FriendlyName" in it's registry data.
This behaviour seems to depend on the O/S. In may case the funtion succeeded always when SPDRP_FRIENDLYNAME is used Windows 10, but only worked for the device that was shown as "...#2" in device manager.
This issue mainly goes down to Windows 10 stopping unsigned drivers from installing, even when the 'driver' is just a .inf file that simply references a (presumably signed) windows DLL, but is there to change the "USB Serial Device" into something meaningful to humans, and recognisable by the application software. I've had to re-write 10 different projects because of this issue.
I now have to check for specific VID/PID, however it is not future proof.

USB Serial Device with Virtual COM port - ReadFile() reads zero bytes if use CreateFile() with USB path

I have a point of sale application that uses Serial Communication ports (RS-232) to communicate with a scale for weighing products. I am now working on being able to support USB devices directly rather than using a Virtual Serial Communication port as they have an annoying tendency to move around.
What we have found is that while Windows 7 seems to automatically create the Virtual Serial Communication port, other versions of Windows such as POS Ready 7 may not. We suspect this is due to a specific .inf file with Windows 7 that is missing from POS Ready 7. Can someone confirm that?
I have a USB sample application that works intermittently. I am having a problem with the USB level communication with the ReadFile() Windows API function. I am using CreateFile() specifying the USB device path to obtain an I/O handle followed by using WriteFile() and ReadFile() to communicate with the scale. The ReadFile() is not providing data in some cases.
Background Information
The particular scale I am using, Brecknell 67xx bench scale, worked with using Virtual Serial Communication port directly out of the box with the point of sale application. I connected the scale to my Windows 7 PC with a USB cable and Windows automatically installed the drivers to create a Virtual Serial port, COM4 in my case. I then configured the application to talk to the scale through COM4 and everything worked fine.
The protocol for using the scale is to send a two byte command, "W\r" (capital letter W followed by a carriage return character) to the scale and to then read a 16 byte response which contains the current weight as well as status information about scale mechanics such as In Motion.
The sample USB application that I am learning from will work successfully providing a weight. Then it will stop working properly with the behavior of the ReadFile() returning zero bytes read. Once it stops working it will continue failing to provide data from the ReadFile() even if I unplug and replug the USB cable or restart my PC.
A previous version of the learning application was hanging on the ReadFile() and when a Break All was done with Visual Studio, a pause followed by a message indicating a deadlock would be displayed. However since I started using SetCommTimeouts() with a 5000 millisecond timeout value in ReadTotalTimeoutConstant I see a consistent 5 second pause before the ReadFile() returns with zero bytes read.
The strange thing is that if I then use the application which opens the Virtual Serial Communication port, COM4, that application works fine and the scale reports the weight of items.
I can then return to the sample application that uses direct USB rather than the Virtual Serial Communication port and it will work fine reporting weights.
However if I then unplug the USB cable connecting scale with PC, which powers off the scale as well, then plug the USB cable back in, the sample application no longer functions correctly and once again I see the pause with timeout.
Then I try using the original point of sale application that depends on Serial Communication ports using the Virtual Serial port, COM4, and that application weighs items just fine.
And when I then retry my sample application, it also will report item weights.
My Questions.
If a USB device creates a Virtual Serial Communications port when it is plugged in then is it required to only use the Virtual Serial port by specifying the communications port, COM4 in my case, in the CreateFile() call?
How is it possible to have direct USB serial communication by using CreateFile() with the USB device path if the device causes Windows to generate a Virtual Communication port?
Is there some way of specifying that any version of Windows is to automatically create a Virtual Serial Communications port for the device when it is plugged in?
Source Code of the Sample USB Application
The source code from my sample USB Windows Console application using Visual Studio 2005 is as follows with the main being at the bottom and much of this being the class for finding a particular USB device and then allowing ReadFile() and WriteFile():
// usb_test_cons.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <windows.h>
#include <setupapi.h>
#include <initguid.h>
#include <stdio.h>
// This is the GUID for the USB device class.
// It is defined in the include file Usbiodef.h of the Microsoft Windows Driver Kit.
// See also https://msdn.microsoft.com/en-us/library/windows/hardware/ff545972(v=vs.85).aspx which
// provides basic documentation on this GUID.
DEFINE_GUID(GUID_DEVINTERFACE_USB_DEVICE, 0xA5DCBF10L, 0x6530, 0x11D2, 0x90, 0x1F, 0x00, 0xC0, 0x4F, 0xB9, 0x51, 0xED);
// (A5DCBF10-6530-11D2-901F-00C04FB951ED)
// Following are standard defines to be used with all of the
// devices that are use through the UIE interface.
#define UIE_DEVICE_ERROR (-11) /* error when accessing the device */
#define UIE_DEVICE_NOT_PROVIDE (-12) /* device is not provided */
#define UIE_DEVICE_ERROR_RANGE (-13) /* range error */
#define UIE_DEVICE_ERROR_COM (-14) /* communication error */
#define UIE_DEVICE_TIMEOUT (-15) /* communication error */
#define UIE_DEVICE_SPECIFIC (-20) /* device specific errors start here */
#define UIE_SCALE_ETX 0x03 /* ETX character */
#define UIE_SCALE_IN_MOTION 0x01 /* scale in motion */
#define UIE_SCALE_ZERO 0x02 /* zero weight */
#define UIE_SCALE_UNDER 0x01 /* under capacity */
#define UIE_SCALE_OVER 0x02 /* over capacity */
#define UIE_SCALE_ERROR UIE_DEVICE_ERROR /* error */
#define UIE_SCALE_NOT_PROVIDE UIE_DEVICE_NOT_PROVIDE /* not provide */
#define UIE_SCALE_TIMEOUT UIE_DEVICE_TIMEOUT /* time out when reading from scale */
#define UIE_SCALE_MOTION (UIE_DEVICE_SPECIFIC-1) /* motion */
#define UIE_SCALE_UNDER_CAPACITY (UIE_DEVICE_SPECIFIC-2) /* under capacity */
#define UIE_SCALE_OVER_CAPACITY (UIE_DEVICE_SPECIFIC-3) /* over capacity */
#define UIE_SCALE_DATAFORMAT (UIE_DEVICE_SPECIFIC-4) /* Data read from scale incorrect format in UieScaleAnalysis() */
#define UIE_SCALE_DATAUNITS (UIE_DEVICE_SPECIFIC-5) /* Units read from scale incorrect in UieScaleAnalysis() */
static SHORT UieScaleStatus(char *puchBuffer, DWORD sLength)
{
UCHAR uchByte;
switch (sLength) {
case 16:
// The scale message is a weight message with a status section.
// Move the buffer pointer to where the status section should begin.
// A status only message has the same format as the status section of a weight message.
puchBuffer += 10;
case 6:
// The scale message may be a status only message if there is a problem with the scale.
// A status only message is 6 characters with the letter S as the second character.
if (*(puchBuffer + 0) != '\n' ||
*(puchBuffer + 1) != 'S' ||
*(puchBuffer + 4) != '\r' ||
*(puchBuffer + 5) != UIE_SCALE_ETX) {
return (UIE_SCALE_DATAFORMAT); /* exit ... */
}
break;
default:
return (UIE_SCALE_DATAFORMAT); /* exit ... */
break;
}
/* --- check status of low byte --- */
uchByte = *(puchBuffer + 3) - (UCHAR)0x30;
if (uchByte & UIE_SCALE_UNDER) {
return (UIE_SCALE_UNDER_CAPACITY);
} else if (uchByte & UIE_SCALE_OVER) {
return (UIE_SCALE_OVER_CAPACITY);
}
/* --- check status of high byte --- */
uchByte = *(puchBuffer + 2) - (UCHAR)0x30;
if (uchByte & UIE_SCALE_IN_MOTION) {
return (UIE_SCALE_MOTION);
} else if (uchByte & UIE_SCALE_ZERO) {
return (0);
} else {
return (TRUE);
}
}
class UsbSerialDevice
{
public:
UsbSerialDevice();
~UsbSerialDevice();
int CreateEndPoint (wchar_t *wszVendorId);
int CloseEndPoint ();
int ReadStream (void *bString, size_t nBytes);
int WriteStream (void *bString, size_t nBytes);
DWORD m_dwError; // GetLastError() for last action
DWORD m_dwErrorWrite; // GetLastError() for last write
DWORD m_dwErrorRead; // GetLastError() for last read
DWORD m_dwBytesWritten;
DWORD m_dwBytesRead;
private:
HANDLE m_hFile;
DWORD m_dwStatError;
COMMTIMEOUTS m_timeOut;
COMSTAT m_statOut;
};
UsbSerialDevice::UsbSerialDevice() :
m_dwError(0),
m_dwErrorWrite(0),
m_dwErrorRead(0),
m_dwBytesWritten(0),
m_dwBytesRead(0),
m_hFile(NULL)
{
}
UsbSerialDevice::~UsbSerialDevice()
{
CloseHandle (m_hFile);
}
int UsbSerialDevice::WriteStream(void *bString, size_t nBytes)
{
BOOL bWrite = FALSE;
if (m_hFile) {
m_dwError = m_dwErrorWrite = 0;
m_dwBytesWritten = 0;
ClearCommError (m_hFile, &m_dwStatError, &m_statOut);
bWrite = WriteFile (m_hFile, bString, nBytes, &m_dwBytesWritten, NULL);
m_dwError = m_dwErrorWrite = GetLastError();
return 0;
}
return -1;
}
int UsbSerialDevice::ReadStream(void *bString, size_t nBytes)
{
BOOL bRead = FALSE;
if (m_hFile) {
m_dwError = m_dwErrorRead = 0;
m_dwBytesRead = 0;
ClearCommError (m_hFile, &m_dwStatError, &m_statOut);
bRead = ReadFile (m_hFile, bString, nBytes, &m_dwBytesRead, NULL);
m_dwError = m_dwErrorRead = GetLastError();
return 0;
}
return -1;
}
int UsbSerialDevice::CreateEndPoint (wchar_t *wszVendorId)
{
HDEVINFO hDevInfo;
m_dwError = ERROR_INVALID_HANDLE;
// We will try to get device information set for all USB devices that have a
// device interface and are currently present on the system (plugged in).
hDevInfo = SetupDiGetClassDevs(&GUID_DEVINTERFACE_USB_DEVICE, NULL, 0, DIGCF_DEVICEINTERFACE | DIGCF_PRESENT);
if (hDevInfo != INVALID_HANDLE_VALUE)
{
DWORD dwMemberIdx;
BOOL bContinue = TRUE;
SP_DEVICE_INTERFACE_DATA DevIntfData;
// Prepare to enumerate all device interfaces for the device information
// set that we retrieved with SetupDiGetClassDevs(..)
DevIntfData.cbSize = sizeof(SP_DEVICE_INTERFACE_DATA);
dwMemberIdx = 0;
// Next, we will keep calling this SetupDiEnumDeviceInterfaces(..) until this
// function causes GetLastError() to return ERROR_NO_MORE_ITEMS. With each
// call the dwMemberIdx value needs to be incremented to retrieve the next
// device interface information.
for (BOOL bContinue = TRUE; bContinue; ) {
PSP_DEVICE_INTERFACE_DETAIL_DATA DevIntfDetailData;
SP_DEVINFO_DATA DevData;
DWORD dwSize;
dwMemberIdx++;
SetupDiEnumDeviceInterfaces(hDevInfo, NULL, &GUID_DEVINTERFACE_USB_DEVICE, dwMemberIdx, &DevIntfData);
if (GetLastError() == ERROR_NO_MORE_ITEMS) break;
// As a last step we will need to get some more details for each
// of device interface information we are able to retrieve. This
// device interface detail gives us the information we need to identify
// the device (VID/PID), and decide if it's useful to us. It will also
// provide a DEVINFO_DATA structure which we can use to know the serial
// port name for a virtual com port.
DevData.cbSize = sizeof(DevData);
// Get the required buffer size. Call SetupDiGetDeviceInterfaceDetail with
// a NULL DevIntfDetailData pointer, a DevIntfDetailDataSize
// of zero, and a valid RequiredSize variable. In response to such a call,
// this function returns the required buffer size at dwSize.
SetupDiGetDeviceInterfaceDetail(hDevInfo, &DevIntfData, NULL, 0, &dwSize, NULL);
// Allocate memory for the DeviceInterfaceDetail struct. Don't forget to
// deallocate it later!
DevIntfDetailData = (PSP_DEVICE_INTERFACE_DETAIL_DATA) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, dwSize);
DevIntfDetailData->cbSize = sizeof(SP_DEVICE_INTERFACE_DETAIL_DATA);
if (SetupDiGetDeviceInterfaceDetail(hDevInfo, &DevIntfData, DevIntfDetailData, dwSize, &dwSize, &DevData))
{
// Finally we can start checking if we've found a useable device,
// by inspecting the DevIntfDetailData->DevicePath variable.
//
// The DevicePath looks something like this for a Brecknell 67xx Series Serial Scale
// \\?\usb#vid_1a86&pid_7523#6&28eaabda&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
//
// The VID for a particular vendor will be the same for a particular vendor's equipment.
// The PID is variable for each device of the vendor.
//
// As you can see it contains the VID/PID for the device, so we can check
// for the right VID/PID with string handling routines.
// See https://github.com/Microsoft/Windows-driver-samples/blob/master/usb/usbview/vndrlist.h
if (wcsstr (DevIntfDetailData->DevicePath, wszVendorId)) {
m_dwError = 0;
m_hFile = CreateFile (DevIntfDetailData->DevicePath, GENERIC_READ | GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0);
if (m_hFile == INVALID_HANDLE_VALUE) {
m_dwError = GetLastError();
} else {
GetCommTimeouts (m_hFile, &m_timeOut);
m_timeOut.ReadIntervalTimeout = 0;
m_timeOut.ReadTotalTimeoutMultiplier = 0;
m_timeOut.ReadTotalTimeoutConstant = 5000;
SetCommTimeouts (m_hFile, &m_timeOut);
m_dwError = GetLastError();
}
bContinue = FALSE; // found the vendor so stop processing after freeing the heap.
}
}
HeapFree(GetProcessHeap(), 0, DevIntfDetailData);
}
SetupDiDestroyDeviceInfoList(hDevInfo);
}
return 0;
}
int _tmain(int argc, _TCHAR* argv[])
{
UsbSerialDevice myDev;
myDev.CreateEndPoint (L"vid_1a86&pid_7523");
switch (myDev.m_dwError) {
case 0:
// no error so just ignore.
break;
case ERROR_ACCESS_DENIED:
wprintf (_T(" CreateFile() failed. GetLastError() = %d\n ERROR_ACCESS_DENIED: Access is denied.\n Is it already in use?\n"), myDev.m_dwError);
break;
case ERROR_GEN_FAILURE:
wprintf (_T(" CreateFile() failed. GetLastError() = %d\n ERROR_GEN_FAILURE: A device attached to the system is not functioning.\n Is it an HID?\n"), myDev.m_dwError);
break;
case ERROR_INVALID_HANDLE:
wprintf (_T(" CreateFile() failed. GetLastError() = %d\n ERROR_INVALID_HANDLE: The handle is invalid.\n CreateFile() failed?\n"), myDev.m_dwError);
break;
default:
wprintf (_T(" CreateFile() failed. GetLastError() = %d\n"), myDev.m_dwError);
break;
}
if (myDev.m_dwError == 0) {
char reqWeight[] = "W\r";
char resWeight[256] = {0};
myDev.WriteStream (reqWeight, strlen (reqWeight));
wprintf (_T(" Sent request now get response.\n"));
Sleep (50);
myDev.ReadStream (resWeight, 16);
wprintf (_T(" Got response.\n"));
if (resWeight[0] != '\n' || resWeight[9] != '\r') {
wprintf (_T(" Unexpected format of response.\n"));
}
short sRet = UieScaleStatus (resWeight, myDev.m_dwBytesRead);
resWeight[9] = 0; // terminate the weight string so that we can write it out.
wprintf (_T(" ScaleStatus = %d, Response from device - \"%S\"\n"), sRet, resWeight + 1);
}
return 0;
}
Additional Information Developed
Overview of INF Files from Microsoft MSDN https://msdn.microsoft.com/en-us/windows/hardware/drivers/install/overview-of-inf-files
Stackoverflow Do I need to write my own host side USB driver for a CDC device
Stackoverflow how to get vendor id and product id of a plugged usb device on windows
Is it possible to “transplant” drivers between machines? has a link to a document Debugging USB Device Installation on Windows and this posting Remove Windows Device Class in Registry has a bit more info.
USB serial driver (Usbser.sys) from Microsoft.
USB device class drivers included in Windows from Microsoft.
The communication of the PC that runs windows (USB host) and the scale (USB device) obeys the USB protocol. If you install libusb for windows you can get similar informations as the PC gets from the USB device, when using lsusb -v. It is possible for a USB device to implement more than one USB class.
If the USB device creates a Virtual COM port it for sure implements the CDC ACM class (Communication Device Class Abstract Control Model) beside this it can also implement other USB classes like Mass Storage class,...
Direct communication with USB device depends also on what device classes it implements and its interfaces and endpoints. If the USB device implements a CDC ACM (Virtual COM) you use the specific RS-232 commands (i.e. https://www.commfront.com/pages/3-easy-steps-to-understand-and-control-your-rs232-devices or send a hexadecimal 'D' to a multimeter to receive the measured value) if it implements the Mass Storage class you normally use bulk transfers
To change the mode of the USB device you use control transfers (see USB in a nutshell)
In this link is how Win determines which driver to load after determining the USB class of the device https://msdn.microsoft.com/en-us/library/windows/hardware/ff538820%28v=vs.85%29.aspx
(https://msdn.microsoft.com/en-us/library/windows/hardware/jj649944%28v=vs.85%29.aspx)
i do not know how Brecknell implemented the CDC ACM device class that is the Virtual COM however normally any Win version that supports USB should be able to load a driver for a CDC ACM device class (Virtual COM) so you are correct this seems to be a problem of the .inf driver file or the driver loading mechanism (maybe a problem of the Brecknell CDC ACM implementation but i do not think so)
Then, if Win loads a working driver the normal way is what you did: use CreateFile() with the COM that is assigned to the USB device.
The strange thing is that if I then use the application which opens the Virtual Serial Communication port, COM4, that application works fine and the scale reports the weight of items. <- this is not strange, strange is that some Win versions do not recognize a CDC USB device .
The standard driver for CDC devices seems to be USBser.sys (https://msdn.microsoft.com/de-de/library/windows/hardware/dn707976%28v=vs.85%29.aspx)
If you search 'windows does not recognize CDC device' you get results
If a USB device creates a Virtual Serial Communications port when it is plugged in then is it required to only use the Virtual Serial port by specifying the communications port, COM4 in my case, in the CreateFile() call? Yes, if a USB device implements a virtual COM it is the easiest way to use this COM to communicate with this device
See also http://www.beyondlogic.org/usbnutshell/usb1.shtml USB in a nutshell
standard USB: device descriptor (class) -> interface -> (configuration) -> endpoint
Testing with a modified USB Serial sample application indicates that when a USB device that creates a Virtual Serial Communications port is unplugged the Virtual Serial Port created is torn down and disappears from the port listing in Device Manager app of Control Panel.
When the device, a USB scale in this case, is plugged in and turned on the Virtual Serial Communications port reappears in Device Manager. However when the Virtual Serial Communications port is created, it is created with default serial port settings (baud rate, parity, etc.) and these may not be the same as for your actual device.
In summary it appears that the Virtual Serial Communications port settings apply regardless of whether the port is opened as a COM port or if the USB device path name is used with the CreateFile().
I am still investigating the Virtual Serial Port not automatically being created when using POS Ready 7 and will update this answer once I know more. However preliminary comparison between Windows 7 and POS Ready 7 is showing that a file that specifies usbser.sys, mdmcpq.inf, that is on my Windows 7 PC is not on the POS Ready 7 terminal in the folder C:\Windows\inf.
See The INF File for a write up on the .inf file structure and the various sections. It is a bit old however it seems to cover the basics in a readable manner.
I modified the function CreateEndPoint() in the question to the following along with a change to the class and the constructor to create a set of default communication port settings for my scale.
The class and the constructor now contain a set of defaults for the communication port settings (9600 baud, 7 data bits, one stop bit, even parity for the scale) and look like:
class UsbSerialDevice
{
public:
UsbSerialDevice();
UsbSerialDevice(DWORD BaudRate, BYTE ByteSize = 8, BYTE Parity = NOPARITY, BYTE StopBits = ONESTOPBIT);
~UsbSerialDevice();
int CreateEndPoint (wchar_t *wszVendorId);
int SetCommPortSettings (DWORD BaudRate, BYTE ByteSize = 8, BYTE Parity = NOPARITY, BYTE StopBits = ONESTOPBIT);
int CloseEndPoint ();
int ReadStream (void *bString, size_t nBytes);
int WriteStream (void *bString, size_t nBytes);
int UpdateSettingsProxy (void);
DWORD m_dwError; // GetLastError() for last action
DWORD m_dwErrorWrite; // GetLastError() for last write
DWORD m_dwErrorRead; // GetLastError() for last read
DWORD m_dwErrorCommState;
DWORD m_dwErrorCommTimeouts;
DWORD m_dwBytesWritten;
DWORD m_dwBytesRead;
COMMTIMEOUTS m_timeOut; // last result from GetCommTimeouts(), updated by UpdateSettingsProxy()
COMSTAT m_statOut; // last result from ClearCommError()
DCB m_commSet; // last result from GetCommState(), updated by UpdateSettingsProxy()
private:
HANDLE m_hFile;
DWORD m_dwStatError;
DCB m_commSetDefault; // the defaults used as standard
wchar_t m_portName[24]; // contains portname if defined for device in form \\.\\COMnn
};
UsbSerialDevice::UsbSerialDevice() :
m_dwError(0),
m_dwErrorWrite(0),
m_dwErrorRead(0),
m_dwBytesWritten(0),
m_dwBytesRead(0),
m_hFile(NULL)
{
// initialize our COM port settings and allow people to change with
memset (&m_commSetDefault, 0, sizeof(m_commSetDefault));
m_commSetDefault.DCBlength = sizeof(m_commSetDefault);
m_commSetDefault.BaudRate = CBR_9600;
m_commSetDefault.ByteSize = 7;
m_commSetDefault.Parity = EVENPARITY;
m_commSetDefault.StopBits = ONESTOPBIT;
m_commSet.fDtrControl = DTR_CONTROL_DISABLE;
m_portName[0] = 0;
}
The function CreateEndPoint() is modified so that after doing the CreateFile() to open the USB device using the pathname of the USB Device, it will now also set the communication port parameters.
An additional experimental change to the method was to check if a communications port name was also created and if so to generate the proper COM port specification to be used with CreateFile(). I plan to split out the CreateEndPoint() method into two methods, one to do a look up of the USB device and a second to actually do the open as I continue my investigation.
The format for the COM port specifier for CreateFile() for COM ports greater than COM9 appear to need the \\.\ as a prefix. See HOWTO: Specify Serial Ports Larger than COM9 from Microsoft Support.
The new version of CreateEndPoint() looks like:
int UsbSerialDevice::CreateEndPoint (wchar_t *wszVendorId)
{
HDEVINFO hDevInfo;
m_dwError = ERROR_INVALID_HANDLE;
// We will try to get device information set for all USB devices that have a
// device interface and are currently present on the system (plugged in).
hDevInfo = SetupDiGetClassDevs(&GUID_DEVINTERFACE_USB_DEVICE, NULL, 0, DIGCF_DEVICEINTERFACE | DIGCF_PRESENT);
if (hDevInfo != INVALID_HANDLE_VALUE)
{
DWORD dwMemberIdx;
BOOL bContinue = TRUE;
SP_DEVICE_INTERFACE_DATA DevIntfData;
// Prepare to enumerate all device interfaces for the device information
// set that we retrieved with SetupDiGetClassDevs(..)
DevIntfData.cbSize = sizeof(SP_DEVICE_INTERFACE_DATA);
dwMemberIdx = 0;
// Next, we will keep calling this SetupDiEnumDeviceInterfaces(..) until this
// function causes GetLastError() to return ERROR_NO_MORE_ITEMS. With each
// call the dwMemberIdx value needs to be incremented to retrieve the next
// device interface information.
for (BOOL bContinue = TRUE; bContinue; ) {
PSP_DEVICE_INTERFACE_DETAIL_DATA DevIntfDetailData;
SP_DEVINFO_DATA DevData;
DWORD dwSize;
dwMemberIdx++;
SetupDiEnumDeviceInterfaces(hDevInfo, NULL, &GUID_DEVINTERFACE_USB_DEVICE, dwMemberIdx, &DevIntfData);
if (GetLastError() == ERROR_NO_MORE_ITEMS) break;
// As a last step we will need to get some more details for each
// of device interface information we are able to retrieve. This
// device interface detail gives us the information we need to identify
// the device (VID/PID), and decide if it's useful to us. It will also
// provide a DEVINFO_DATA structure which we can use to know the serial
// port name for a virtual com port.
DevData.cbSize = sizeof(DevData);
// Get the required buffer size. Call SetupDiGetDeviceInterfaceDetail with
// a NULL DevIntfDetailData pointer, a DevIntfDetailDataSize
// of zero, and a valid RequiredSize variable. In response to such a call,
// this function returns the required buffer size at dwSize.
SetupDiGetDeviceInterfaceDetail(hDevInfo, &DevIntfData, NULL, 0, &dwSize, NULL);
// Allocate memory for the DeviceInterfaceDetail struct. Don't forget to
// deallocate it later!
DevIntfDetailData = (PSP_DEVICE_INTERFACE_DETAIL_DATA) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, dwSize);
DevIntfDetailData->cbSize = sizeof(SP_DEVICE_INTERFACE_DETAIL_DATA);
if (SetupDiGetDeviceInterfaceDetail(hDevInfo, &DevIntfData, DevIntfDetailData, dwSize, &dwSize, &DevData))
{
// Finally we can start checking if we've found a useable device,
// by inspecting the DevIntfDetailData->DevicePath variable.
//
// The DevicePath looks something like this for a Brecknell 67xx Series Serial Scale
// \\?\usb#vid_1a86&pid_7523#6&28eaabda&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
//
// The VID for a particular vendor will be the same for a particular vendor's equipment.
// The PID is variable for each device of the vendor.
//
// As you can see it contains the VID/PID for the device, so we can check
// for the right VID/PID with string handling routines.
// See https://github.com/Microsoft/Windows-driver-samples/blob/master/usb/usbview/vndrlist.h
if (wcsstr (DevIntfDetailData->DevicePath, wszVendorId)) {
HKEY hKey;
m_dwError = 0;
// To find out the serial port for our scale device,
// we'll need to check the registry:
hKey = SetupDiOpenDevRegKey(hDevInfo, &DevData, DICS_FLAG_GLOBAL, 0, DIREG_DEV, KEY_READ);
if (hKey != INVALID_HANDLE_VALUE) {
DWORD dwSize = 0, dwType = 0;
wchar_t lpData[16] = {0};
dwType = REG_SZ;
dwSize = sizeof(lpData);
LONG queryStat = RegQueryValueEx(hKey, _T("PortName"), NULL, &dwType, (LPBYTE)&lpData[0], &dwSize);
RegCloseKey(hKey);
if (queryStat == ERROR_SUCCESS) {
wcscpy (m_portName, L"\\\\.\\");
wcsncat (m_portName, lpData, dwSize / sizeof(wchar_t));
}
} else {
m_dwError = GetLastError();
}
m_hFile = CreateFile (DevIntfDetailData->DevicePath, GENERIC_READ | GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0);
if (m_hFile == INVALID_HANDLE_VALUE) {
m_dwError = GetLastError();
} else {
m_dwError = 0;
GetCommState (m_hFile, &m_commSet);
m_commSet = m_commSetDefault;
SetCommState (m_hFile, &m_commSet);
m_dwErrorCommState = GetLastError();
GetCommState (m_hFile, &m_commSet);
GetCommTimeouts (m_hFile, &m_timeOut);
m_timeOut.ReadIntervalTimeout = 0;
m_timeOut.ReadTotalTimeoutMultiplier = 0;
m_timeOut.ReadTotalTimeoutConstant = 5000;
SetCommTimeouts (m_hFile, &m_timeOut);
GetCommTimeouts (m_hFile, &m_timeOut);
m_dwErrorCommTimeouts = GetLastError();
}
bContinue = FALSE; // found the vendor so stop processing after freeing the heap.
}
}
HeapFree(GetProcessHeap(), 0, DevIntfDetailData);
}
SetupDiDestroyDeviceInfoList(hDevInfo);
}
return 0;
}
POS Ready 7 Investigation
Looking back on the Windows 7 PC which seems to work fine with the scale, we looked in the driver details for the Virtual Serial Communications port using Device Manager from the Control Panel. The driver details indicated that the driver being used was CH341S64.SYS provided by www.winchiphead.com and the Property "Inf name" has a value of oem50.inf. I found a forum post http://doityourselfchristmas.com/forums/showthread.php?14690-CH340-USB-RS232-Driver which provides a link to a driver download at http://www.winchiphead.com/download/CH341/CH341SER.ZIP however another version available from http://www.wch.cn/download/CH341SER_ZIP.html may be more up to date.
Putting the downloaded zip file, CH341SER.ZIP from the later on to the POS Ready 7 terminal, I unzipped the contents and ran SETUP.EXE in the folder CH341SER (there were two folders in the zip file and the one called INSTALL seemed for device development) which displayed a dialog and allowed me to install the CH341SER.INF. Once the install completed, when I plugged in the USB scale, the device was recognized and a Virtual Serial Communications port was created and my test application worked.
I did find some documentation however it was all in Chinese. Google Translate provided a readable version of the USB device documentation. It looks like there is additional work to be done for device management when the scale may be unplugged/replugged while in use.
One other strange thing is that the scale is now using a different COM port name, COM5 rather than COM4. Looking in the Advanced Settings it appears that COM4 is "In Use" though not showing in the list of ports. Further experiments indicates that the COM port name used for the scale device depends on which of the two front panel USB ports are plugged into. I had originally plugged into the left one and today, plugged into the right USB port with the result of the Virtual Serial Communications port being created with a new COM port name.
However since we are using the USB path in the CreateFile(), no change was needed in the USB sample test application.
Further testing with POS Ready 7 using three USB to Serial converter cables showed that different vendor's cables had the same vendor id and product code in the USB path. The USB path also changed depending on which USB port a cable was plugged into. In some cases only the last digit in the path name differed. An interesting experiment would be if a USB hub is connected to a USB port and then USB connections are made to the hub what does the path name look like then?
You are confusing two issues, and it's probably not viable for us to tell them apart.
I say this because you link ReadFile problems to the device name. However, ReadFile works on a HANDLE. The function which takes a name and converts it into a HANDLE is called CreateFile. That means ReadFile doesn't even know on what name it's operating.
This misunderstanding also explains a few other behaviors. For instance, when you unplug the device, the HANDLE becomes invalid, and it stays invalid. Replugging the device may restore the name, but not the HANDLE.

SetupDiEnumDriverInfo returns different results on Windows 7 and Windows 8 / 10

I am debugging an application that should retrieve information about all smart card reader drivers installed on a Windows system.
The code below works on Windows 7 (64 bit):
QSet<QString> getSmartCardDriverModuleNames()
{
QSet<QString> moduleNames;
// the GUID for the smart card reader device setup class
wchar_t deviceClassGuidString[] = L"{50dd5230-ba8a-11d1-bf5d-0000f805f530}";
GUID deviceClass;
CLSIDFromString(deviceClassGuidString, &deviceClass);
HDEVINFO deviceInfoSet = SetupDiGetClassDevs(&deviceClass, NULL, NULL, 0);
if (deviceInfoSet == INVALID_HANDLE_VALUE)
{
return moduleNames;
}
SP_DEVINFO_DATA deviceInfoData;
deviceInfoData.cbSize = sizeof(deviceInfoData);
for (DWORD deviceIndex = 0;
SetupDiEnumDeviceInfo(deviceInfoSet, deviceIndex,
&deviceInfoData);
deviceIndex++)
{
if (SetupDiBuildDriverInfoList(deviceInfoSet, &deviceInfoData,
SPDIT_COMPATDRIVER))
{
SP_DRVINFO_DATA_W driverInfoData;
driverInfoData.cbSize = sizeof(driverInfoData);
for (DWORD driverIndex = 0;
SetupDiEnumDriverInfo(deviceInfoSet, &deviceInfoData,
SPDIT_COMPATDRIVER, driverIndex,
&driverInfoData);
driverIndex++)
{
// Omitted: get service name and add to moduleNames.
}
SetupDiDestroyDriverInfoList(deviceInfoSet, &deviceInfoData,
SPDIT_COMPATDRIVER);
}
}
SetupDiDestroyDeviceInfoList(deviceInfoSet);
return moduleNames;
}
This code correctly finds the installed drivers when run on Windows 7, but finds no driver at all on Windows 8 or Windows 10 (both 64 bit), even though some drivers are installed.
It turns out (by adding extra logging and debug code) that under Windows 8 and 10 the first call to SetupDiEnumDriverInfo fails. In this case, by adding a call to GetLastError() I get ERROR_NO_MORE_ITEMS, which is the normal behaviour expected when the end of the list is reached (see the documentation).
So, no errors are detected, but the result is empty.
In the documentation of the Windows API I have found no changes from Windows 7 to Windows 8, 10, so no adaptation to the above code should be needed.
Have I overlooked something? Do you have any hint as to what I should check next?

FILE_NOT_FOUND when trying to open COM port C++

I am trying to open a com port for reading and writing using C++ but I can't seem to pass the first stage of actually opening it. I get an INVALID_HANDLE_VALUE on the handle
with GetLastError FILE_NOT_FOUND. I have searched around the web for a couple of days I'm fresh out of ideas. I have searched through all the questions regarding COM on this website too.
I have scanned through the existing ports (or so I believe) to get the name of the port right.
I also tried combinations of _T("COM1") with the slashes, without the slashes, with colon, without colon and without the _T
I'm using windows 7 on 64 bit machine.
this is the code i got
I'll be glad for any input on this
void SendToCom(char* data, int len)
{
DWORD cbNeeded = 0;
DWORD dwPorts = 0;
EnumPorts(NULL, 1, NULL, 0, &cbNeeded, &dwPorts);
//What will be the return value
BOOL bSuccess = FALSE;
LPCSTR COM1 ;
BYTE* pPorts = static_cast<BYTE*>(malloc(cbNeeded));
bSuccess = EnumPorts(NULL, 1, pPorts, cbNeeded, &cbNeeded, &dwPorts);
if (bSuccess){
PORT_INFO_1* pPortInfo = reinterpret_cast<PORT_INFO_1*>(pPorts);
for (DWORD i=0; i<dwPorts; i++)
{
//If it looks like "COMX" then
size_t nLen = _tcslen(pPortInfo->pName);
if (nLen > 3)
{
if ((_tcsnicmp(pPortInfo->pName, _T("COM"), 3) == 0) ){
COM1 =pPortInfo->pName;
//COM1 ="\\\\.\\COM1";
HANDLE m_hCommPort = CreateFile( COM1 ,
GENERIC_READ|GENERIC_WRITE, // access ( read and write)
0, // (share) 0:cannot share the COM port
NULL, // security (None)
OPEN_EXISTING, // creation : open_existing
FILE_FLAG_OVERLAPPED, // we want overlapped operation
NULL // no templates file for COM port...
);
if (m_hCommPort==INVALID_HANDLE_VALUE)
{
DWORD err = GetLastError();
if (err == ERROR_FILE_NOT_FOUND) {
MessageBox(hWnd,"ERROR_FILE_NOT_FOUND",NULL,MB_ABORTRETRYIGNORE);
}
else
if(err == ERROR_INVALID_NAME) {
MessageBox(hWnd,"ERROR_INVALID_NAME",NULL,MB_ABORTRETRYIGNORE);
}
else
{
MessageBox(hWnd,"unkown error",NULL,MB_ABORTRETRYIGNORE);
}
}
else{
WriteAndReadPort(m_hCommPort,data);
}
}
pPortInfo++;
}
}
}
}
The Solution is to use
The Problem is, if your port is Bigger then 9 then you have to use the Syntax
LPCWSTR szPortName = L"\\\\.\\COM11";.
If you are on Windows 10 - running all system updates might help !
I had the same issue that opening port "COM4" returned an error ERROR_FILE_NOT_FOUND. When running the program as "Administrator" it worked. Now after a updating to 1511 the program can open "COM4" even not running as "Administrator".
http://www.cplusplus.com/forum/windows/163855/
Use CreateFileA(...) instead of CreateFile(...)
ERROR_FILE_NOT_FOUND can be produced from CreateFile(L"\\\\.\\COM1", ...) and CreateFile(L"COM1:", ...) after using the Device Manager to change the assigned COM Port number. Disabling and re-enabling the device, or unplugging and reconnecting the USB adapter resolves the issue.
A useful test to confirm whether it is your program or the system is to send data to the port in command prompt. A successful test will show an empty line. A failed test will show an error message.
C:\drop>echo > \\.\COM1
The system cannot find the file specified.
C:\drop>echo > \\.\COM1
C:\drop>