12 Jul
2022
12 Jul
'22
7:45 p.m.
On Tue Jul 12 18:43:38 2022 +0000, **** wrote:
Zebediah Figura replied on the mailing list:
On 7/12/22 13:01, Claire Girka wrote: > From: Claire Girka <claire@sitedethib.com> > > Do not assume the underlying driver will return meaningful data, as it > may not support BusQueryContainerID which will be queried in a next commit. > --- > dlls/hidclass.sys/pnp.c | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/dlls/hidclass.sys/pnp.c b/dlls/hidclass.sys/pnp.c > index 873c55c4a67..afc7b6e933d 100644 > --- a/dlls/hidclass.sys/pnp.c > +++ b/dlls/hidclass.sys/pnp.c > @@ -71,7 +71,7 @@ static minidriver *find_minidriver(DRIVER_OBJECT *driver) > static NTSTATUS get_device_id(DEVICE_OBJECT *device, BUS_QUERY_ID_TYPE type, WCHAR *id) > { > IO_STACK_LOCATION *irpsp; > - IO_STATUS_BLOCK irp_status; > + IO_STATUS_BLOCK irp_status = { .Status = STATUS_NOT_IMPLEMENTED, .Information = 0 }; > KEVENT event; > IRP *irp; > > @@ -87,8 +87,14 @@ static NTSTATUS get_device_id(DEVICE_OBJECT *device, BUS_QUERY_ID_TYPE type, WCH > if (IoCallDriver(device, irp) == STATUS_PENDING) > KeWaitForSingleObject(&event, Executive, KernelMode, FALSE, NULL); > > - wcscpy(id, (WCHAR *)irp_status.Information); > - ExFreePool((WCHAR *)irp_status.Information); > + if (irp_status.Information && !irp_status.Status) I think "!irp_status.Status" implies "irp_status.Information". > + wcscpy(id, (WCHAR *)irp_status.Information); > + else > + id[0] = 0; > + > + if (irp_status.Information) > + ExFreePool((WCHAR *)irp_status.Information); > + > return irp_status.Status; > } > I don't think it makes sense to return a failure status but still report output buffers. I would instead fill the default "empty" ID in the caller, and just don't modify the output buffer if the call fails. _______________________________________________ wine-gitlab mailing list -- wine-gitlab@winehq.org To unsubscribe send an email to wine-gitlab-leave@winehq.org
`!irp_status.Status` should probably imply `irp_status.Information` but it is not currently the case. For unhandled `IRP_MN_QUERY_ID` types, `winebus` will set the status *based* on the (uninitialized) value of `irp_status.Information`.
This is probably a bug in `winebus`, though.