MVP Rescue Media Builder 2-3-2-0 - Keyboard and Mouse Issue
***** Software and Hardware *****
MVPAssistant_2-3-2-0.zip
Acronis Cyber Protect Home Office Essentials, build 40173
Windows 11 Pro, Version 22H2, OS build 22621.963
Laptop: ASUS ProArt Studiobook H7600ZW-DB76
Logitech M505 USB mouse with Unifying receiver
Logitech K520 USB keyboard with Unifying receiver
***** Problem *****
On a Windows 11 Pro laptop, I use MVP Rescue Media Builder 2-3-2-0 to create an USB WinRE.
When I run the WinrRE, the following happened:
The Logitech M505 USB mouse with Unifying receiver worked. The USB Unifying receiver was directly connected to the laptop.
The Logitech K520 USB keyboard worked in a very peculiar manner.
If I typed a few letters, nothing happened until 15 seconds later when the letters would appear.
However, if I continually moved the Logitech mouse as I typed the letters, the letters immediately appeared.
The ASUS driver download web page does not have an ASUS driver for the keyboard or mouse. Therefore, the keyboard and mouse use a Microsoft generic keyboard driver according to Device Manager.
I tried building the USB WinRE both with Easy and Advance mode.
The laptop keyboard had the same issue.
It is unclear why the Logitech mouse must be moving in order for the keyboard text to appear in the textbox.
Thank you for your help.


- Anmelden, um Kommentare verfassen zu können

John,
I concur with Bruno here. Looking in Device Manager on your running Windows installation open Human Interface Devices then look for Logitech USB Input Device. This driver is the Unifying device driver. Adding that driver should resolve your issues with the keyboard and mouse. The generic MS drivers held in the RE image provide support for the mouse and keyboard but not the Unifying receiver.
Add this driver per Bruno's instructions
- Anmelden, um Kommentare verfassen zu können

BrunoC - I appreciate your quick response.
I contacted Logitech. Logitech said, "Please be inform that your device is a plug-and-play device that will use the native driver of your computer. Kindly just make sure it is directly plugged into your computer's USB port and not into a hub."
"Mouse and keyboard support on Windows 11"
Unclear why the website won't let me place a hyperlink here.
The Logitech web page says they use the Microsoft drivers.
As you said, Logitech may be wrong.
Using Device Manager on my running Windows 11 Pro system, under "Human Interface Devices", I found an entry for "Logitech USB Input Device" driver. However, using the NirSoft DriverView, I did not see the "Logitech USB Input Device" unifhid.inf driver listed which seemed strange since the Device Manager saw it.
I next ran MVPAssistant. I frequently found that "Analyze..." threw a dialog with the error that "unhandled exception has occurred in your application ...". However, "Deep analyis..." [note spelling error] tended not to have this problem.
I am still unclear about the difference between "Analyze" versus "Deep analyis".
In the "Online Drivers" panel, "HID Class" had "*oem53.inf" which was the Logitech unifhid.inf.
I selected "*oem53.inf" and then used "Request to add unifhid.inf".
In the Suggested Update panel, I checked all items.
I then used Drivers -> "Apply chosen suggested updates".
The "Drivers in Image" panel showed the following:
HIDClass
*oem15.inf [oem53.inf]
Logitech USB Input Device
I assume this means that the Logitech oem15.inf driver was already included in the original Source file: winre.wim.
I ran the WinRE. I was pleased to see that typing from the Logitech keyboard worked as expected.
I also ran the NirSoft DriverView in the WinRE with the view all drivers option checked. I was surprised to see no reference in any column to either oem15.inf, oem53.inf, or "Logitech USB Input Device".
I was curious to see what would happen if I did not include the Logitech unifhid.inf so did not select "*oem53.inf" to be included in the "Apply chosen suggested updates". Upon running the WinRE, I found that typing from the Logitech keyboard worked as expected. This makes sense if the Logitech oem15.inf was already in the original Source file: winre.wim.
How does MVPAssistant determine what is *Boot Critical? For example, in Device Manager, if I have the Logitech unitek dongle connected, I see under "Human Interface Devices" the entry for the "Logitech USB Input Device" driver. If I remove the Logitech unitek dongle, I no longer see the entry for the "Logitech USB Input Device" driver. However, in MVPAssistant in the "Online Drivers" panel, I always see the Logitech driver "*oem53.inf" irrespective of whether the Logitech gongle is connected or not connected. So where does MVPAssistant look to determine what is *Boot Critical? What is the programming API, registry entry, or whatever is used?
By-the-way, my laptop screen is 3840 x 2400. I found that using a screen size of 3840 x 2400 with scaling 100% worked well with the WinRE. Is this what you recommend? There was a bit of bar cutoff near the Search text box.
Thank you for writing this wonderful program. The Acronis Rescue Media Builder (build 40173) has not worked for me. Acronis Technical Support has so far been unable to make it work. Without your program, I would not be able to create an USB rescue drive that worked.
Thank you again,
John
- Anmelden, um Kommentare verfassen zu können

John, so pleased to hear that you were able to do a build which worked well for you.
As for the exception error when running Analyze... it would be helpful if you could provide the information detailing that exception.
As a general suggestion, please open the Help for the rescue builder as it may answer some of your concerns.
A deep analysis just goes further into the devices. If you want to have some fun, from the Tools menu open the MVP Driver Analyzer. This is a stand alone program which does a more detailed analysis and view. This was actually written before the rescue builder in order to work out the code I needed for the builder.
A boot critical driver is one which is labeled as Boot Critical, meaning it should be automatically loaded if there is a PnP device which requires it. It is part of the info returned about a driver from the system. Further understanding may be achieved by looking into the DISM driver servicing commands, particularly /Get-Drivers and /Get-DriverInfo.
Color is meaningful in the Online Drivers list. Those in green are drivers which are determined to be the right drivers for actual found PnP devices. Blue drivers are compatible with PnP devices, but not necessarily used.
If you saw *oem15.inf [oem53.inf] in the Image drivers only after applying the suggested updates, then it was installed by you. If you saw it before applying updates then it would appear right after running the analysis.
I'd be interested to see what your Online Drivers and Image Drivers look like originally, before applying any updates.
Did you show any drivers under the Mouse and Keyboard classes?
As for the Logitech/Microsoft driver question, I believe that Windows will be able to install a Logitech sourced driver automatically when finding the device without needing to install it directly from Logitech.
I hope this helps provide some clarity into what is a real can of worms.
- Anmelden, um Kommentare verfassen zu können

John,
Glad to hear of your success. What you see in Device Manager under HID as the Logitech USB Input Device is actually placed there by Logitech software which provides a Profile for the wireless signal (nRF24L) (2.4 GHz) signal. Without the profile available your mouse and keyboard compete with each other for control of the receiver thus the issue you had with the devices not functioning as expected. Adding in the OEM53.inf driver in-turn added the profile to the media. The OEM15.inf is the Windows Generic Logitech USB device driver that is native to Windows images. The number designation may change from installation to installation as it is determined by Windows during installation per the PNP standard.
The Acronis Media Builder does not analyze the driver stack as deeply as the MVP Driver Analyzer tool so fails to find the dependency of software based drivers such as the Logitech Unifying driver.
What this all means is that the default WinRE on your system had the OEM15.inf driver natively but does not contain the functions of the OEM53.inf driver by default so if more than one device is using the same receiver the conflict between devices will exist.
Working with Bruno on the MVP tool project these dependencies were discovered to be lacking in the available driver locator tools at the time of development so providing the capability to do this in the tool is something you will not find in other device driver locator tools.
We appreciate your feedback.
- Anmelden, um Kommentare verfassen zu können