Calling WinUSB from an application

OSR_Community_User · December 18, 2006, 6:48pm

Look at the UMDF samples - there are new directives you can add to your
sources files to tell the WDK that you’re trying to build binaries
compatible with XP.

We used:

WIN32_WINNT_VERSION=$(LATEST_WIN32_WINNT_VERSION)
_NT_TARGET_VERSION=$(_NT_TARGET_VERSION_WINXP)
NTDDI_VERSION=$(LATEST_NTDDI_VERSION)

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Daniel E. Germann
Sent: Monday, December 18, 2006 3:40 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Calling WinUSB from an application

Well, supporting WinUSB from both Windows XP and Windows Vista is
getting
more interesting.

I have a DLL that talks to our device on XP just fine (less the bulk
endpoints, which I’m going to use WinUSB for). I’ve been building the
DLL
using the Windows Server 2003 SP1 DDK (3790.1830). I thought I’d cut
over
to the Vista RTM WDK (6000) before tackling WinUSB to make sure there
were
no “hiccups”.

Unfortunately, there were. I can build my DLL with the WDK, but it
won’t
run on XP now because there are unsatisfied external references to
MSVCRT.DLL:
__CxxFrameHandler3
_except_handler4_common

It looks like these references are due to the new compiler version in
the
WDK (Visual Studio 2005 vintage, I presume). On XP systems, the
installed
version of MSVCRT.DLL doesn’t include these entry points.

It seems like my only option is to install Visual Studio 2005 and hope
the
REDIST directory includes a copy of MSVCRT.DLL that I can install
side-by-side with my DLL. Is that the “official recommended” approach?

And, if so, what do I do when I start building my device co-installer
and
“EnumPropPages32” DLLs from the WDK, and still need to support XP
systems?
I don’t think WFP will let me update the MSVCRT.DLL in SYSTEM32…

-Dan

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Doron_Holan · December 18, 2006, 7:02pm

Also from what I understand, the use of EnumPropPages32 is discouraged
and you should use instead DIF_ADDPROPERTYPAGE_ADVANCED

http://msdn2.microsoft.com/en-us/library/ms793120.aspx

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, December 18, 2006 3:47 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Calling WinUSB from an application

Look at the UMDF samples - there are new directives you can add to your
sources files to tell the WDK that you’re trying to build binaries
compatible with XP.

We used:

WIN32_WINNT_VERSION=$(LATEST_WIN32_WINNT_VERSION)
_NT_TARGET_VERSION=$(_NT_TARGET_VERSION_WINXP)
NTDDI_VERSION=$(LATEST_NTDDI_VERSION)

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Daniel E. Germann
Sent: Monday, December 18, 2006 3:40 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Calling WinUSB from an application

Well, supporting WinUSB from both Windows XP and Windows Vista is
getting
more interesting.

I have a DLL that talks to our device on XP just fine (less the bulk
endpoints, which I’m going to use WinUSB for). I’ve been building the
DLL
using the Windows Server 2003 SP1 DDK (3790.1830). I thought I’d cut
over
to the Vista RTM WDK (6000) before tackling WinUSB to make sure there
were
no “hiccups”.

Unfortunately, there were. I can build my DLL with the WDK, but it
won’t
run on XP now because there are unsatisfied external references to
MSVCRT.DLL:
__CxxFrameHandler3
_except_handler4_common

It looks like these references are due to the new compiler version in
the
WDK (Visual Studio 2005 vintage, I presume). On XP systems, the
installed
version of MSVCRT.DLL doesn’t include these entry points.

It seems like my only option is to install Visual Studio 2005 and hope
the
REDIST directory includes a copy of MSVCRT.DLL that I can install
side-by-side with my DLL. Is that the “official recommended” approach?

And, if so, what do I do when I start building my device co-installer
and
“EnumPropPages32” DLLs from the WDK, and still need to support XP
systems?
I don’t think WFP will let me update the MSVCRT.DLL in SYSTEM32…

-Dan

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Daniel_E_Germann · December 18, 2006, 7:52pm

Thanks for the suggestions. I will take a look at
DIF_ADDPROPERTYPAGE_ADVANCED.

And, for the record, I found an easy fix – and only my own stupidity kept
me from seeing it sooner. If I build from the WDK’s XP build environment, I
get a DLL that works under XP. I tried this earlier, but it didn’t dawn on
me until a few minutes ago that I was still looking in the
objchk_wlh_x86\i386 directory for the rebuilt DLL, which (of course) still
had references to the entry points I was trying to eliminate.

-Dan

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Also from what I understand, the use of EnumPropPages32 is discouraged
and you should use instead DIF_ADDPROPERTYPAGE_ADVANCED

http://msdn2.microsoft.com/en-us/library/ms793120.aspx

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, December 18, 2006 3:47 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Calling WinUSB from an application

Look at the UMDF samples - there are new directives you can add to your
sources files to tell the WDK that you’re trying to build binaries
compatible with XP.

We used:

WIN32_WINNT_VERSION=$(LATEST_WIN32_WINNT_VERSION)
_NT_TARGET_VERSION=$(_NT_TARGET_VERSION_WINXP)
NTDDI_VERSION=$(LATEST_NTDDI_VERSION)

-p

Brian_Hindman · December 18, 2006, 8:19pm

Dan,

As to the inf file. Thanks for the pointers!! I have been able to get the following inf file to install WinUSB under Vista x86 and Windows XP Pro (haven’t yet tested under x64 platforms). I removed ia64 support as I didn’t see a WinUSB coinstaller for it. After editing the inf file (see below) with correct VID/PID/GUID/STRINGS, you should be able to use it. Just put it in a directory. From that directory, make “amd64” and “x86” subdirectories and place the wdf and winusb coinstallers in them. Then, once you’ve plugged in your device, just point the Hardware Installer to it and (fingers crossed) it should work. If anyone sees anything else I need to do (or if I’ve missed something), let me know. Be patient, as it took a bit of time for the Hardware Wizard to install everything…

Thanks,
–Brian

;=================== Version section ====================

[Version]
Signature = “$Windows NT$”
Class = MyDeviceClass
ClassGuid = {11111111-2222-3333-4444-555555555555}
Provider = %ProviderName%
DriverVer = MM/DD/YYYY,n.n.n.n
CatalogFile = MyWinUSBInstall.cat

; ========== Manufacturer/Models sections ===========

[Manufacturer]
%ProviderName% = MyDevice_WinUSB,NTx86,NTamd64

[MyDevice_WinUSB.NTx86]
%USB\MyDevice.DeviceDesc% =USB_Install, USB\VID_xxxx&PID_xxxx

[MyDevice_WinUSB.NTia64]
%USB\MyDevice.DeviceDesc% =USB_Install, USB\VID_xxxx&PID_xxxx

[MyDevice_WinUSB.NTamd64]
%USB\MyDevice.DeviceDesc% =USB_Install, USB\VID_xxxx&PID_xxxx

; =================== Installation ===================

[USB_Install]
Include=winusb.inf
Needs=WINUSB.NT

[USB_Install.Services]
Include=winusb.inf
AddService=WinUSB,0x00000002,WinUSB_ServiceInstall

[WinUSB_ServiceInstall]
DisplayName = %WinUSB_SvcDesc%
ServiceType = 1
StartType = 3
ErrorControl = 1
ServiceBinary = %12%\WinUSB.sys

[USB_Install.Wdf]
KmdfService=WINUSB, WinUsb_Install

[WinUSB_Install]
KmdfLibraryVersion=1.5

[USB_Install.HW]
AddReg=Dev_AddReg

[Dev_AddReg]
HKR,DeviceInterfaceGUIDs,0x00010000,“{55555555-4444-3333-2222-111111111111}”

[USB_Install.CoInstallers]
AddReg=CoInstallers_AddReg
CopyFiles=CoInstallers_CopyFiles,NTx86,NTamd64

[CoInstallers_AddReg]
HKR,CoInstallers32,0x00010000,“WinUSBCoInstaller.dll”,“WdfCoInstaller01005.dll,WdfCoInstaller”

[CoInstallers_CopyFiles.NTx86]
x86\WinUSBCoInstaller.dll
x86\WdfCoInstaller01005.dll

[CoInstallers_CopyFiles.NTamd64]
amd64\WinUSBCoInstaller.dll
amd64\WdfCoInstaller01005.dll

[DestinationDirs]
CoInstallers_CopyFiles=11

; =================== Strings ===================

[Strings]
ProviderName=“MyCompany”
USB\MyDevice.DeviceDesc=“My Device using WinUSB only”
WinUSB_SvcDesc=“WinUSB driver”

OSR_Community_User · December 21, 2006, 7:09pm

"Randy Aull" wrote in message news:xxxxx@ntdev...

I'm happy you think it is "too easy". That was kind of the point. It
is absolutely supported.

Well, Randy, you were right on -- it was (almost) that easy! A few function
calls, a little re-reading of the docs, and I'm getting some of the data I'm
expecting the bulk endpoint to send. And I'm pretty sure the missing data
is due to something that isn't right with the hardware.

But I just ran into a new problem. I turned some code back on in my app
that asks for input reports from the HID portion of my device, and I got a
BSOD in wdf01000.sys. It looks like it's happening when my app closes a
handle to WinUSB. I'm guessing that isn't supposed to happen. Any
recommendations?

-Dan

****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by
try-except,
it must be protected by a Probe. Typically the address is just plain bad or
it
is pointing at freed memory.
Arguments:
Arg1: ff798000, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: f168d4b0, If non-zero, the instruction address which referenced the
bad memory
address.
Arg4: 00000000, (reserved)

Debugging Details:

Could not read faulting driver name

READ_ADDRESS: ff798000

FAULTING_IP:
Wdf01000!FxUsbPipe::InitPipe+19
f168d4b0 f3a5 rep movsd

MM_INTERNAL_CODE: 0

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x50

LAST_CONTROL_TRANSFER: from f168c8d3 to f168d4b0

STACK_TEXT:
f3cb9a6c f168c8d3 ff798000 00000001 821c7a68
Wdf01000!FxUsbPipe::InitPipe+0x19
f3cb9a8c f168cffd ff797ab4 00000000 821c7a68
Wdf01000!FxUsbInterface::SetInfo+0x38
f3cb9b64 f168d105 00000000 ff797aa0 00000000
Wdf01000!FxUsbInterface::SelectSetting+0x1f2
f3cb9b80 f1688574 00000000 00000000 f3cb9bd4
Wdf01000!FxUsbInterface::SelectSettingByIndex+0x7e
f3cb9ba4 f188351a feea2318 7de38590 00000000
Wdf01000!imp_WdfUsbInterfaceSelectSetting+0x4c4
f3cb9bd4 f1880f19 fef21710 00000000 00000000 WinUSB!WinUSB_SetInterface+0x52
f3cb9bf0 f18806c8 fef21710 82604320 82604384
WinUSB!WinUSB_ResetDefaults+0x25
f3cb9c04 f16b6fd4 7d8d2b08 ff0f5738 82604384 WinUSB!WinUSB_Cleanup+0x6c
f3cb9c18 f16b767d 7d8d2b08 82604320 ff0f585c
Wdf01000!FxFileObjectFileCleanup::Invoke+0x24
f3cb9c38 f16b7dfe 00000000 828f0ca8 fea13030
Wdf01000!FxPkgGeneral::OnCleanup+0x57
f3cb9c54 f16add9a ff0f5738 f3cb9ca4 804e37f7
Wdf01000!FxPkgGeneral::Dispatch+0xcb
f3cb9c60 804e37f7 ff4e8530 ff0f5738 ff0f5738
Wdf01000!FxDevice::Dispatch+0x7f
f3cb9c70 8056a8e8 828f0c90 82fed040 00000001 nt!IopfCallDriver+0x31
f3cb9ca4 80566901 82421020 ff4e8530 0012019f nt!IopCloseFile+0x27c
f3cb9cd4 80566aab 82421020 828f0ca8 82fed040
nt!ObpDecrementHandleCount+0x119
f3cb9cfc 80566b1c e1d259e0 828f0ca8 00000130
nt!ObpCloseHandleTableEntry+0x14d
f3cb9d44 80566b66 00000130 00000001 00000000 nt!ObpCloseHandle+0x87
f3cb9d58 804de7ec 00000130 0006f68c 7c90eb94 nt!NtClose+0x1d
f3cb9d58 7c90eb94 00000130 0006f68c 7c90eb94 nt!KiFastCallEntry+0xf8
WARNING: Frame IP not in any known module. Following frames may be wrong.
0006f67c 00000000 00000000 00000000 00000000 0x7c90eb94

FOLLOWUP_IP:
Wdf01000!FxUsbPipe::InitPipe+19
f168d4b0 f3a5 rep movsd

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Wdf01000!FxUsbPipe::InitPipe+19

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4549b23a

STACK_COMMAND: kb

FAILURE_BUCKET_ID: 0x50_Wdf01000!FxUsbPipe::InitPipe+19

BUCKET_ID: 0x50_Wdf01000!FxUsbPipe::InitPipe+19

Followup: MachineOwner

kd> r
eax=00000001 ebx=ff064650 ecx=00000005 edx=f3cb9a0b esi=ff798000
edi=ff064708
eip=f168d4b0 esp=f3cb9a60 ebp=f3cb9a6c iopl=0 nv up ei pl nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010206
Wdf01000!FxUsbPipe::InitPipe+0x19:
f168d4b0 f3a5 rep movsd ds:ff798000=????????
es:ff064708=00000000

OSR_Community_User · December 22, 2006, 11:14am

You are correct, that is not the intended behavior:)

Is there any indication that a select interface call to the device failed?

From: xxxxx@lists.osr.com on behalf of Daniel E. Germann
Sent: Thu 12/21/2006 4:09 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Calling WinUSB from an application

"Randy Aull" wrote in message news:xxxxx@ntdev...

I'm happy you think it is "too easy". That was kind of the point. It
is absolutely supported.

Well, Randy, you were right on -- it was (almost) that easy! A few function
calls, a little re-reading of the docs, and I'm getting some of the data I'm
expecting the bulk endpoint to send. And I'm pretty sure the missing data
is due to something that isn't right with the hardware.

But I just ran into a new problem. I turned some code back on in my app
that asks for input reports from the HID portion of my device, and I got a
BSOD in wdf01000.sys. It looks like it's happening when my app closes a
handle to WinUSB. I'm guessing that isn't supposed to happen. Any
recommendations?

-Dan

****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by
try-except,
it must be protected by a Probe. Typically the address is just plain bad or
it
is pointing at freed memory.
Arguments:
Arg1: ff798000, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: f168d4b0, If non-zero, the instruction address which referenced the
bad memory
address.
Arg4: 00000000, (reserved)

Debugging Details:

Could not read faulting driver name

READ_ADDRESS: ff798000

FAULTING_IP:
Wdf01000!FxUsbPipe::InitPipe+19
f168d4b0 f3a5 rep movsd

MM_INTERNAL_CODE: 0

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x50

LAST_CONTROL_TRANSFER: from f168c8d3 to f168d4b0

STACK_TEXT:
f3cb9a6c f168c8d3 ff798000 00000001 821c7a68
Wdf01000!FxUsbPipe::InitPipe+0x19
f3cb9a8c f168cffd ff797ab4 00000000 821c7a68
Wdf01000!FxUsbInterface::SetInfo+0x38
f3cb9b64 f168d105 00000000 ff797aa0 00000000
Wdf01000!FxUsbInterface::SelectSetting+0x1f2
f3cb9b80 f1688574 00000000 00000000 f3cb9bd4
Wdf01000!FxUsbInterface::SelectSettingByIndex+0x7e
f3cb9ba4 f188351a feea2318 7de38590 00000000
Wdf01000!imp_WdfUsbInterfaceSelectSetting+0x4c4
f3cb9bd4 f1880f19 fef21710 00000000 00000000 WinUSB!WinUSB_SetInterface+0x52
f3cb9bf0 f18806c8 fef21710 82604320 82604384
WinUSB!WinUSB_ResetDefaults+0x25
f3cb9c04 f16b6fd4 7d8d2b08 ff0f5738 82604384 WinUSB!WinUSB_Cleanup+0x6c
f3cb9c18 f16b767d 7d8d2b08 82604320 ff0f585c
Wdf01000!FxFileObjectFileCleanup::Invoke+0x24
f3cb9c38 f16b7dfe 00000000 828f0ca8 fea13030
Wdf01000!FxPkgGeneral::OnCleanup+0x57
f3cb9c54 f16add9a ff0f5738 f3cb9ca4 804e37f7
Wdf01000!FxPkgGeneral::Dispatch+0xcb
f3cb9c60 804e37f7 ff4e8530 ff0f5738 ff0f5738
Wdf01000!FxDevice::Dispatch+0x7f
f3cb9c70 8056a8e8 828f0c90 82fed040 00000001 nt!IopfCallDriver+0x31
f3cb9ca4 80566901 82421020 ff4e8530 0012019f nt!IopCloseFile+0x27c
f3cb9cd4 80566aab 82421020 828f0ca8 82fed040
nt!ObpDecrementHandleCount+0x119
f3cb9cfc 80566b1c e1d259e0 828f0ca8 00000130
nt!ObpCloseHandleTableEntry+0x14d
f3cb9d44 80566b66 00000130 00000001 00000000 nt!ObpCloseHandle+0x87
f3cb9d58 804de7ec 00000130 0006f68c 7c90eb94 nt!NtClose+0x1d
f3cb9d58 7c90eb94 00000130 0006f68c 7c90eb94 nt!KiFastCallEntry+0xf8
WARNING: Frame IP not in any known module. Following frames may be wrong.
0006f67c 00000000 00000000 00000000 00000000 0x7c90eb94

FOLLOWUP_IP:
Wdf01000!FxUsbPipe::InitPipe+19
f168d4b0 f3a5 rep movsd

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Wdf01000!FxUsbPipe::InitPipe+19

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4549b23a

STACK_COMMAND: kb

FAILURE_BUCKET_ID: 0x50_Wdf01000!FxUsbPipe::InitPipe+19

BUCKET_ID: 0x50_Wdf01000!FxUsbPipe::InitPipe+19

Followup: MachineOwner

kd> r
eax=00000001 ebx=ff064650 ecx=00000005 edx=f3cb9a0b esi=ff798000
edi=ff064708
eip=f168d4b0 esp=f3cb9a60 ebp=f3cb9a6c iopl=0 nv up ei pl nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010206
Wdf01000!FxUsbPipe::InitPipe+0x19:
f168d4b0 f3a5 rep movsd ds:ff798000=????????
es:ff064708=00000000

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at ListServer/Forum