DisplayLink overloads Windows Kernel

[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 or the trojan protector.sys?

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...er-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?

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