I need to create a control device object for an NDIS miniport to allow client to manipulate adapter through user IOCTLs. I have studied examples, so my initialization code looks like this:
NdisZeroMemory(Adapter->DeviceMajorFunctionTable, (IRP_MJ_MAXIMUM_FUNCTION + 1) * sizeof(PDRIVER_DISPATCH));
Adapter->DeviceMajorFunctionTable[IRP_MJ_CREATE] = ClassCreateClose;
Adapter->DeviceMajorFunctionTable[IRP_MJ_CLEANUP] = ClassCleanup;
Adapter->DeviceMajorFunctionTable[IRP_MJ_CLOSE] = ClassCreateClose;
Adapter->DeviceMajorFunctionTable[IRP_MJ_READ] = ClassRead;
Adapter->DeviceMajorFunctionTable[IRP_MJ_WRITE] = ClassWrite;
Adapter->DeviceMajorFunctionTable[IRP_MJ_DEVICE_CONTROL] = ClassDeviceControlDispatch;
NdisInitUnicodeString(
&Adapter->devName,
UIO_DEVICE
);
NdisInitUnicodeString(
&Adapter->devLinkName,
UIO_SYMLINK
);
ndo.Header.Type = NDIS_OBJECT_TYPE_DEFAULT;
ndo.Header.Revision = NDIS_DEVICE_OBJECT_ATTRIBUTES_REVISION_1;
ndo.Header.Size = NDIS_SIZEOF_DEVICE_OBJECT_ATTRIBUTES_REVISION_1;
ndo.DeviceName = &Adapter->devName;
ndo.SymbolicName = &Adapter->devLinkName;
ndo.MajorFunctions = Adapter->DeviceMajorFunctionTable;
ndo.ExtensionSize = sizeof(MP_ADAPTER);
ndo.DefaultSDDLString = NULL;
ndo.DeviceClassGuid = 0;
Status = NdisRegisterDeviceEx(
NdisDriverHandle,
&ndo,
&Adapter->pUserIoDo,
&Adapter->hDevice
);
…
This call returns NDIS_STATUS_SUCCESS, so I assume everything is working. However, when call CreateFile on the device file name “\.\DeviceName” from user-space, I get the Win32 error code 50, which is “Error Not Supported” or “Request is not supported.”
What am I missing here?
I forgot to add the parameters for my CreateFile call:
CreateFile(
“\\.\miniDevice”,
GENERIC_READ | GENERIC_WRITE,
0,
NULL,
OPEN_EXISTING,
0,
NULL
);
CreateFile returns Win32 error code 50 (decimal): “Error Not Supported”
Is your IRP_MJ_CREATE handler getting called?
Is UIO_DEVICE == L"\Device\miniDevice" and UIO_SYMLINK == L"\DosDevices\miniDevice"?
Yes.
From: xxxxx@lists.osr.com on behalf of xxxxx@honeywell.com
Sent: Thursday, March 2, 2017 3:20:45 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Problem with NdisRegisterDeviceEx…
Is UIO_DEVICE == L"\Device\miniDevice<file:>" and UIO_SYMLINK == L"\DosDevices\miniDevice<file:>"?
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></file:></file:>
Try:
hDevice = CreateFile(szDevice,
GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
Is your IRP_MJ_CREATE handler getting called?
My IRP_MJ_CREATE handler is NOT being called. I never see the request in the driver.
<
Is UIO_DEVICE == L"\Device\miniDevice" and UIO_SYMLINK ==
L"\DosDevices\miniDevice"?
Yes. Those are the actual device and link names.
Yeah, I tried adding the FILE_ATTRIBUTE_NORMAL=128 flag earlier today and got the same error.
From: xxxxx@lists.osr.com on behalf of xxxxx@honeywell.com
Sent: Thursday, March 2, 2017 3:28:45 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Problem with NdisRegisterDeviceEx…
Try:
hDevice = CreateFile(szDevice,
GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
—
NTDEV is sponsored by OSR
Visit the list online at: http:
OSR Online NTDEV Listhttp:
www.osronline.com
OSR Online is the homepage for Windows driver writers. The NTDEV, NTFSD, and NTTALK lists are world-wide peer support forums administered by OSR.
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
[https://www.osr.com/wp-content/uploads/seminar_map4_big.png]http:
Windows Driver Development Training from OSRhttp:
www.osr.com
Learn Windows driver development, file system development, and debugging from developer/instructors with real-world experience. Seminars taught world-wide.
To unsubscribe, visit the List Server section of OSR Online at http:
ListServer/Forumhttp:
www.osronline.com
List Rules and Etiquette. You get a list of the list rules when you join. But nobody seems to read those notes, so we’re posting some of the most important rules here:</http:></http:></http:></http:></http:></http:></http:>
Yeah, I tried adding the FILE_ATTRIBUTE_NORMAL=128 flag earlier today and got the same error.
The code you posted looks correct. So the issue is probably in some code you didn’t post. Check if your ClassCreateClose function is getting called. Set a breakpoint on ndis!ndisCreateIrpHandler , and step through it a bit to see if it seems to go somewhere. Use !ndiskd.minidriver -devices to check if your device is known to NDIS. Use !devobj miniDevice to see if your device is known to the kernel.
A couple minor notes (these won’t cause error 50):
You don’t need to keep the function table in your adapter context. NDIS caches the dispatch table. You can just throw the function table on the stack, and reclaim once NdisRegisterDeviceEx returns. Likewise with the UNICODE_STRINGs and the buffers they point to.
It’s hard to say without seeing the rest of your code, but setting ExtensionSize = sizeof(MP_ADAPTER) looks a little fishy. You probably use MP_ADAPTER as your MiniportAdapterContext. You’ll want a different structure for your device extension.
@OP are you creating the control device object in your DriverEntry before creating any miniports?
IIRC once there was a requirement (or a gotcha) that a miniport instance must be created first.
– pa
Thanks for the reply. This problem is peculiar in that I don’t see ClassCreateClose() called at all. I can try the breakpoint you mentioned, but NDIS is definitely aware of the driver as data is flowing through the NDIS portion of the code without issue. I was wondering if I’m calling NdisRegisterDeviceEx in the wrong place. I’m calling it near the end of MiniportInitializeEx. Should I be making this call in DriverEntry instead?
Point taken on the function table and yeah I’m aware those need to be unique context structures, I was planning to update that later.
From: xxxxx@lists.osr.com on behalf of Jeffrey Tippet
Sent: Friday, March 3, 2017 1:22:09 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] Problem with NdisRegisterDeviceEx…
The code you posted looks correct. So the issue is probably in some code you didn’t post. Check if your ClassCreateClose function is getting called. Set a breakpoint on ndis!ndisCreateIrpHandler , and step through it a bit to see if it seems to go somewhere. Use !ndiskd.minidriver -devices to check if your device is known to NDIS. Use !devobj miniDevice to see if your device is known to the kernel.
A couple minor notes (these won’t cause error 50):
You don’t need to keep the function table in your adapter context. NDIS caches the dispatch table. You can just throw the function table on the stack, and reclaim once NdisRegisterDeviceEx returns. Likewise with the UNICODE_STRINGs and the buffers they point to.
It’s hard to say without seeing the rest of your code, but setting ExtensionSize = sizeof(MP_ADAPTER) looks a little fishy. You probably use MP_ADAPTER as your MiniportAdapterContext. You’ll want a different structure for your device extension.
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>
> I’m calling it near the end of
MiniportInitializeEx. Should I be making this call in DriverEntry instead?
Try to call it *after* MiniportInitializeEx has returned. Like, call it in your CheckForHang function (only once, of course).
– pa
No, no.
NdisRegisterDeviceEx works perfectly in the MiniportInitializeEx context. It may even work in DriverEntry context.
> No, no.
NdisRegisterDeviceEx works perfectly in the MiniportInitializeEx context. It may
even work in DriverEntry context.
IIRC it was a bug in some version, fixed in later version or even update. The OP did not mention the Windows version.
– pa
Since CreateFile call does not arrive to the OP’s driver (“ClassCreateClose”) it may be something wrong with the security or device name. Look at the control device in WinObj or OSR deviceTree. As Jeffrey wrote, something is wrong with the dev. extension too.
– pa
You can try MAXIMUM_ALLOWED for the security in the call to create file, this will tell you if it is security or the device iself that is the problem.
Anyway, a few suggestions:
-
Zero your ndo memory
-
Set header.type to NDIS_OBJECT_TYPE_DEVICE_OBJECT_ATTRIBUTES
-
Set header.suze to sizeof(NDIS_DEVICE_OBJECT_ATTRIBUTES)
-
Give the SDDL string somethign useful to overcome any security issues.
Doing it this way has always worked for me, so give it a go.
