I have implemented a class that gets local printers and, depending on the application option, uses one of the local printer available.
Firstly, the class enumerates the printers (EnumPrinters - PRINTER_ENUM_LOCAL) and saves the corresponding PRINTER_INFO_2. Then, it gets printer capabilities (DeviceCapabilites) and DEVMODE. Each class instance will access one printer.
When application selects the printing option, it selects which printer will be used and its corresponding instance of the class. Then, this instance creates the device context:
m_hdc = CreateDC (m_pi2->pDriverName, m_pi2->pPrinterName, NULL, m_pdm));
where
HDC m_hdc;
PRINTER_INFO_2 * m_pi2;
DEVMODE * m_pdm;
and process all printing data accordingly.
The problem is that sometimes, the CreateDC return NULL and GetLastError() return ERROR_FILE_NOT_FOUND(2).
I mean 'sometimes' because in other machines, with same printer, same processor, same Windows XP SP3 image and same test data, the CreateDC processes correctly. In addition, the reinstalling the system and application the problem disappears sometimes no.
I am looking forward to hearing any suggestion that helps me to find out the issue.
Thank you in advance.
It sounds like a problem loading a file required by the printer driver. You could use Process Monitor (a free SysInternals tool downloadable from microsoft.com) to get a bunch of information about what's going on at the time of the error. I'd do a capture and look at failed file and registry accesses. The fact that it fails intermittently on one particular machine seems consistent with a messed up driver configuration.
Another thing you could try is to create an information context rather than a device context. You can't print with an IC, but you can query information about the device, which may be a way to get additional information.
Related
I am writing a driverkit extension whose goal is to block some categories of USB devices, such as flash drives. The driver should block (match to) any device of the relevant device classes, except those, which are whitelisted (based on their vendor and product ID). The whitelist can be set dynamically by user of the application.
The question is, how to pass these data to the driver as reading from a file or something like Windows registry is not available in the DriverKit. The tricky part is that the driver requires the whitelist data before the device is matched.
From what I understood, rejection of device is possible by returning an error from Start() method and returning from it prematurely. I got an idea to send the data while the driver is running this function, however this is not possible as the communication via IOUserClass is not available until the Start method returns.
Is this somehow doable?
As far as I'm aware, communicating with user space apps from the initial Start() method is not possible from DriverKit extensions. As you say, IOUserClients are the mechanism to use for user space communication, and those aren't available until the service is started and registered. You can have your driver match IOResources/IOUserResources so it is always loaded, but each matched service starts up an independed process of your dext, and I'm not aware of a way to directly communicate between these instances.
If I understand you correctly, you're trying to block other drivers from acquiring the device. I don't think the solution you have in mind will help you with this. If you return success from Start(), your dext will drive the device. If you return failure, no driver is loaded for the device, because matching has already concluded. So other drivers would never get a chance anyway, regardless of whether the device is on your allow-list or deny-list.
It's new in DriverKit 21 (i.e. macOS Monterey), and I've not had a chance to try it yet, but there is an API for reading files, OSMappedFile. I would imagine that the DriverKit sandbox will have something to say about which files a dext can open, but this seems like an avenue worth exploring whether you can open configuration files this way.
Note that none of this will help you during early boot, as your dext will never be considered for matching at that time. And you may not be able to get required entitlements from Apple to build a dext which matches USB device classes rather than specific product/vendor ID patterns. (Apologies for repeating myself, but other users may come across this answer and not be aware of this issue.)
As a part of my project, I get an event notification every time a Service is Started or Stopped using the WMI class Win32_Service through an EventSink.
I want to detect the application which had requested "services.exe" to start a particular service.
Till now, I tried Monitoring ALPC calls between any process and "services.exe" and got a Message_ID every time a process communicates (sends/receives) any information to/from "services.exe" using the ALPC Class. I would like to know what these messages are so that I can decode a StartService() or a StopService() procedure.
Is there any way to detect which application starts/stops a service?
The best way to do this, in my opinion, would be from kernel-mode using the PsSetCreateProcessNotifyRoutine/Ex/Ex2 kernel-mode callback.
If you're going to be using PsSetCreateProcessNotifyRoutine, you will receive less information than if you were using the Extended version of the kernel-mode callback (the Ex one). However, you can still query information such as the image file path of the parent process (or the one being created) by using PsLookupProcessByProcessId to get a pointer to the _EPROCESS structure and then relying on SeLocateProcessImageName (undocumented, however it is accessible in WDK by default).
The SeLocateProcessImageName routine will rely internally on that _EPROCESS structure, since information like the path of the process image on-disk is all tracked by the Windows kernel there.
If you're going to be using the Ex version of the kernel-mode callback, then you eliminate the need to do what is mentioned above. The Ex version of the routine is more recent than the non-Ex version.
The routine prototype for the callback routine will be:
VOID
CreateProcessNotifyRoutineEx(
PEPROCESS Process,
HANDLE ProcessId,
PPS_CREATE_NOTIFY_INFO CreateInfo
)
As seen above, you get a pointer to the _PS_CREATE_NOTIFY_INFO structure. You can then access the ImageFileName and CommandLine fields to filter for services.exe (make sure you filter properly to not catch it for a rogue copy - so ensure full path indicates its the real one) and gain more insight into why it was being invoked (if such information is exposed via the command-line... I cannot remember - nonetheless, you can still detect its creation and be aware of who spawned it).
To determine the parent who was responsible for the process creation operation of services.exe (e.g. if it relied on the Service Manager which in turn resulted in the spawning of it), you can rely on the ParentProcessId field (under the _PS_CREATE_NOTIFY_INFO structure as well). The SeLocateProcessImageName trick will work perfectly here.
SeLocateProcessImageName is undocumented so here is the routine prototype:
NTSTATUS
NTAPI
SeLocateProcessImageName(
PEPROCESS Process,
PUNICODE_STRING *ImageName
);
At-least with the latest Windows 10 WDK, it's already available by default. If you wanted to though, you can use a dynamic import with MmGetSystemRoutineAddress.
Resources:
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntddk/nf-ntddk-pssetcreateprocessnotifyroutine
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntddk/nf-ntddk-pssetcreateprocessnotifyroutineex
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntddk/nf-ntddk-pssetcreateprocessnotifyroutineex2
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/content/wdm/nf-wdm-mmgetsystemroutineaddress
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntifs/nf-ntifs-pslookupprocessbyprocessid
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntddk/ns-ntddk-_ps_create_notify_info
I have code running as a Windows service which would like to determine the resolution of the directly attached monitors.
(Yes, I appreciate that the user may be interacting with the machine via RDP, VDI etc., so this doesn't always make sense - but this is just an optimisation, so in the common case where there is a single directly-attached desktop, it would still be useful.)
I'd like to use ::GetSystemMetrics(SM_CXVIRTUALSCREEN) but it returns 0, as I'm running in session 0. Similarly EnumDisplayDevices looks like it will only work for the present interactive session.
We'd like to be able to do this even when no user is logged in.
Is there a way to explore hardware screen resolutions even as a service?
The documentation for EnumDisplayDevices() clearly says:
The EnumDisplayDevices function lets you obtain information about the display devices in the current session.
Since a service runs in session 0, and there are no displays in session 0, there is no monitor information for it to enumerate.
Try using EnumDisplayMonitors() instead.
I have a Windows application that interacts with some hardware. A handle to the hardware is opened with CreateFile, and we control the hardware using DeviceIoControl.
I'm attempting to update an application which uses this hardware to open the hardware in an exclusive mode, so that other programs can't access the hardware at the same time (the hardware has mutable state that I can't have changed out from under me). I do this by passing 0 as the dwShareMode parameter to CreateFile. After making this change, I am still able to run two separate instances of my application. Both calls to CreateFile in both processes are successful. Neither returns INVALID_HANDLE_VALUE.
I believe one of several things is happening, and I'm asking for help narrowing the problem down.
I badly misunderstand the dwShareMode parameter
dwShareMode doesn't have any effect on DeviceIoControl - only ReadFile or WriteFile
The driver itself is somehow responsible for respecting the dwShareMode parameter and our driver is written badly. This, sadly, isn't totally unheard of.
Edit Option 2 is nonsense. dwShareMode should prevent the 2nd CreateFile from happening, DeviceIoControl has nothing to do with it. It must be option #1 or option #3
The Question:
Is the device driver responsible for looking at the dwShareMode parameter, and rejecting requests if someone has already opened a handle without sharing, or is the OS responsible?
If the device driver is responsible, then I'm going to assume #3 is happening. If the OS is responsible, then it must be #1.
Some additional Clues:
IRP_MJ_CREATE documentation suggests that the sharing mode does indeed get passed down to the device driver
I believe that sharing rules are only enforced on some devices. In many (most?) cases enforcing sharing rules on the device object itself (as opposed to on objects within the device namespace) would make no sense.
Therefore, it must be the responsibility of the device driver to enforce these rules in those rare cases where they are required. (Either that or the device driver sets a flag to instruct the operating system to do so, but there doesn't seem to be a flag of this sort.)
In the case of a volume device, for example, you can open the device with a sharing mode of 0 even though the volume is mounted. [The documentation for CreateFile says you must use FILE_SHARE_WRITE but this does not appear to be true.]
In order to gain exclusive access to the volume, you use the FSCTL_LOCK_VOLUME control code.
[That's a file system driver, so it might not be a typical case. But I don't think it makes a difference in this context.]
Serial port and LPT drivers would be an example of a device that should probably enforce sharing rules. I think there may be some applicable sample code, perhaps this would shed light on things?
Edited to add:
I've had a look through the Windows Research Kernel source (this is essentially the same as the Windows Server 2003 kernel) and:
1) The code that opens a device object (by sending IRP_MJ_CREATE to the driver) does not appear to make any attempt to enforce the sharing mode parameter, though it does check access permissions and enforces the Exclusive flag for the driver;
2) I've also searched the code for references to the structure member that holds the requested dwShareMode. As far as I can see it is written into the relevant structure by the internal function that implements CreateFile, and later passed to the device driver, but otherwise ignored.
So, my conclusion remains the same: enforcing the sharing mode rules, or providing an alternative mechanism if appropriate, is the responsibility of the device driver.
(The kernel does, however, provide functions such as IoCheckShareAccess to assist file system drivers in enforcing sharing rules.)
In cases where we open a COM port with :
CreateFile(devname,GENERIC_READ | GENERIC_WRITE,
0,
0,
OPEN_EXISTING,
0,
0);
It doesnt allow another application to open the same COM port until the previous handle is closed. I would suggest walking through serenum.sys to check if it has a role here.
I always set my drivers Imagepath directly.(C:\Windows\System32\drivers\abc.sys)
But I just knew many device drivers set their ImagePath to %SystemRoot%\system32\svchost.exe -k netsvcs
This is Lanmanworkstation driver's registry hive.
I guess Lanmanworkstation driver's image file is mrxsmb.sys
But they didn't put 'System32\drivers\mrxsmb.sys'. Why.
What does svchost.exe -k netsvcs mean?
Even though there is no certain path, StartService function works well.
How does Service Manager(? i'm not sure) find the driver's image path?
Is there an advantage using this?
What if I decide to use this way, are there my driver codes should modify?
You are confusing between device drivers and services.
svchost.exe is used to share the same process between multiple services. The implementation is internal to Windows so use outside of Windows is not supported.
If you write a device driver (for hardware, or a filter driver) or do not work for Microsoft, you cannot use svchost.
The reason for the confusion is because old style (NT4), non-plug-and-play drivers can be started using the Service Control Manager APIs.
svchost is a host process for other services, contained in DLLs. The part after the "-k" indicates the service group. You can find the service DLL path in HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters in the ServiceDll value. I'm guessing the reason it still starts correctly if you remove the image path is because the service type is set to SERVICE_WIN32_SHARE_PROCESS, and the SCM probably ignores the image path (not sure about this).
svchost.exe is a "multi-purpose" service. It incorporates multiple services in one single exe file, each of which can be seperately controlled using e.g. services management console. The parameters to svchost.exe states the "subservice" inside the exe file.
As startService() is not a control message to the service itself but instead only the request to start a certain executable (which itself must "know" that it is a service (and wich service) and will then register with service control manager), windows will simply execute the binary that ImagePath points to.
In this case (LanManWorkstation) this binary is svchost.exe, the parameter given to it is -k netsvc. This lets svchost.exe know which of the many service it provides should be started.
As usual, the binary doesn't need to contain all the function in itself but can also load additional libraries. mrxsmb.sys may well be such a library, though I'm not sure of this point.
So this answer is more of a "how does it work in general" than a "yes, netsvc and mrxsmb.sys are LanManWorkstation".