DisplayLink overloads Windows Kernel

[JH_MMC]

Dear Community, we're developing a product working under DisplayLink with this 10" USB LCD (http://lilliputdirect.com/lilliput-um1010-touchscreen).

We're detecting some troubles with the Windows 7 PosReady and the Windows Kernel due this is overloaded for the DisplayLink driver.

Our scenario is:
- Win 7 PosReady x32bits
- The USB 10" display by USB 2.0 connection. Driver DisplayLink_7.6M1
- No peripherals (the display is for Maintenance of the system)

We see the next analyzing the system kernel consumption:

In Windows 7 32-bit kernel stack apparently are 12 Kbytes.
What is the Kernel stack size of the displayLink software? It is a "normal" environment this memory?

Any knows any recommendation to (something that is available to disable) release the kernel load.

Many thanks in advance!
Regards

[AlbanRampon]

Hello JH,

We do not support, test or maintain drivers for Windows Embedded and family.
As Microsoft indicates the Windows 7 POSready will be end of life in 4 months (https://support.microsoft.com/en-gb/lifecycle?p1=16152), we are unlikely to be able to start development/test for that OS.

Unfortunately, the only recommendation we can do without analysis would be to try with different versions (http://www.displaylink.com/downloads/windows) of our drivers to see if one works. However, even if one is working, any change you make to the system may break it as your configuration is not tested.

Kind regards,
Alban
Minimum PC requirements for Windows drivers (support.displaylink.com/knowledgebase/articles/524951-what-are-the-minimum-pc-requirements-for-windows-d).

[JH_MMC]

Many thanks for your quick reply AlbanRampon... But in Win7 Pro the problem is the same...

Regards

Hello JH,

We do not support, test or maintain drivers for Windows Embedded and family.
As Microsoft indicates the Windows 7 POSready will be end of life in 4 months (https://support.microsoft.com/en-gb/lifecycle?p1=16152), we are unlikely to be able to start development/test for that OS.

Unfortunately, the only recommendation we can do without analysis would be to try with different versions (http://www.displaylink.com/downloads/windows) of our drivers to see if one works. However, even if one is working, any change you make to the system may break it as your configuration is not tested.

Kind regards,
Alban
Minimum PC requirements for Windows drivers (support.displaylink.com/knowledgebase/articles/524951-what-are-the-minimum-pc-requirements-for-windows-d).

[JH_MMC]

Many thanks for your reply AlbanRampon.

But we tested under Windows 7 Pro x32bits and we have the BOSD too...

Regards.

[jdelatorre]

Dear Alban,

Really, we would like to have more info about the software stack size that DisplayLink requires, mainly for knowing if some feature can be shutdown.
The main problem is that displaylink related drivers take many space at this kernel.

Indeed, could be useful to know if some driver previous versión has a lighter Windows Kernel stack usage.

Thanks a lot,

[AlbanRampon]

Hey JH,

In that case, if you provide the system_details.txt and memory minidump our support tool would gather from your Win7 Pro, I will have a look!

Generally, it's because of an inadequate primary graphics card driver. But with 7.6 M1, it wouldn't be surprising as this is a 2 year old driver which doesn't benefit from the last 2 years of bug fixing. Do you get the same BSoDs on Win7 Pro x86 when using 7.9 M7 (http://www.displaylink.com/downloads/file?id=576) and the latest primary graphics card drivers?
On Windows Embedded 7 with 7.9, you will need to restart the DisplayLink Manager service manually to try.

If we comment on the size of the software, then we have to keep updating that comment. That's not something we specify. We unfortunately don't have the resource to create custom drivers with or without selected features. I hope you can understand it is even more difficult to justify allocating resource to an OS we don't support and will be end of lifed in 4 months.
Previous drivers versions are available from the download page by scrolling down: http://www.displaylink.com/downloads/windows

We are releasing 8.0 Beta 4 within a week and you'll also be able to try. However it will not be suitable for production. We have heard it might not need the manual service restart on Windows Embedded 7, an unplanned improvement for this unsupported and already end-of-lifed OS.

Kind regards,
Alban

[JH_MMC]

Hey AlbanRampon!

Attached you have the BSOD pic, the MINIDUMP of Windows, the system details using “DisplayLink USB Graphics Software for Windows 7.9 M7”.

Thanks in advance!

[AlbanRampon]

Hello,

Logs provided are not from big Windows, but a Windows Embedded Standard...
I've never seen such calling stack or BSoD, and I've seen a few.

There is a trip on the carpet with the Intel graphics driver, us and something else I haven't seen before, but the Microsoft tool is accusing another module called volmgr.sys
I'd recommend removing DL drivers, updating Intel graphics driver and then try to install DisplayLink version 7.7 M4 (http://www.displaylink.com/downloads/file?id=5).

Kind regards,
Alban


************************************************** *****************************
* *
* Bugcheck Analysis *
* *
************************************************** *****************************
UNEXPECTED_KERNEL_MODE_TRAP (7f)
BugCheck 7F, {8, 8e907750, 0, 0}
*** ERROR: Module load completed but symbols could not be loaded for dcrypt.sys
*** ERROR: Module load completed but symbols could not be loaded for Protector.sys
*** ERROR: Symbol file could not be found. Defaulted to export symbols for igdkmd32.sys -
Probably caused by : volmgr.sys ( volmgr!RtlStringCbPrintfW+3a )

[JH_MMC]

Thanks! We will try your detailed info...

When I will test it i'll post our feedback.

Regards

[JH_MMC]

Dear AlbanRampon, sorry for my last reply...

Attached you have the dump file extracted following your recommended instructions.

Please could you check it and let me know what we're doing wrong... :(

Thanks in advance!

[AlbanRampon]

That's alright, I've got the history here and we don't receive many of these!

Would you know what this protector.sys intercepting the calls is?
Is it the Bank of China protector.sys (http://www.freefixer.com/library/file/protector.sys-64878/) or the trojan protector.sys (http://www.threatexpert.com/files/protector.sys.html)?

I see you use a disk encryption utility as well.

I would advise you try with a simpler system for the troubleshooting.
Because the call is handled by 4 different parties, removing a few layers would be helpful.

I've trolled the web for that bug check, as everyone does, and I could find that some layers intercepting calls to the hard disk have created similar things in the past: http://www.sevenforums.com/bsod-help-support/137529-windows-7-crashing-after-update.html

Kind regards,
Alban


UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f)
This means a trap occurred in kernel mode, and it's a trap of a kind that the kernel isn't allowed to have/catch (bound trap) or that is always instant death (double fault). The first number in the bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: 8c639750
Arg3: 00000000
Arg4: 00000000

[jdelatorre]

Dear all,

May I understand that there is no relation between Intel graphics callings and Displaylink driver? I supposed that Displaylink driver called someway intel graphic cards for doing some image processing, am I right?:confused:

Kind regards, thanks in advance.

[jdelatorre]

Dear Alban,

Protector.sys is a security software that checks the system looking for unexpected / non registered processes.

Kind regards,

Juan

[AlbanRampon]

Followed up by email following private message.
To progress, I think we need the answer to the tests without these intermediary layers.

[jdelatorre]

Dear Alban,

I attach you our Platform people message, please tell me if it helps anyway, best regards:

“In our scenario, it is not possible to remove any layer from the system, as all of them are required to enforce security in our systems. The protector.sys file is part of Checker solution (from GMV), and it is in charge of monitoring security settings in the computer. It’s the interaction with this file what is causing issues when operating at the same time than your driver, as observed by our technicians. The issue appears when Checker is already installed in the Operating System and the DisplayLink Driver for the USB Lilliput UM-1010 is installed. At that moment, and during the installation, the system goes to BSoD.

If installed in a different order, this is, DisplayLink driver first and Checker software secondly, the BSoD occurs when the system is rebooted with the same Error Code than in the other scenario. We have already tested a lot of other drivers and software, in collaboration with GMV, and it seems it’s the DL driver what is causing the BSoD, and we contacted you so this could be clarified.

[AlbanRampon]

Good evening,
I am afraid I miss one part of the reasoning. How do we go from 1. to 2. ?

1a. The DisplayLink driver works on its own. This is what I had asked to test and even if it is not possible to remove any layer, it sounds like they did it anyway.
1b. The tool made especially to snoop on running processes works on its own.
1c. They don't work **together**.

2. Your conclusion is DL is responsible for the crash.

What is the result of the analysis of the crash dump with GMV debug symbols? What kind of function is called at the time of crash? Is there an explanation as to why there is an exception going through their driver? I don't have their symbols and we don't have the OS. They are higher in the call stack.

I believe testing a "lot of other drivers" is not relevant to fix the problem. I did not use the argument that we have millions of devices running in the field to refuse helping on an OS we don't support.

May I get the crash dumps with the full Windows 7 OS, access to that GMV software, so I can get an internal reproduction from our engineering team? As we have neither Windows POSReady, or this application monitoring processes, it won't be possible for them to progress this. Without repro, debugging is close to impossible.
Having access to what investigation and analysis GMV/you have done to reach these conclusions would also be helpful.
I recommend you use the email address I replied you on to provide these elements as I don't believe posting third party software on forums is appropriate. Also, GMV might not wish information about their monitoring application being posted publicly.

Kind regards,
Alban