VBoxMP::DxgkDdiEscape: unsupported escape code (0x4e564441)

[Shawn]

Can some devs review the log file.

Host: Fedora 17 64 bit;

Guest: Windows 7 SP1 64 bit;

Problem: The guest stopped responding. So I clicked pause, but then the upper portion of the screen remained black.

My full HDD is encrypted using LUKS. If I include the core dump will the password be out in the open?

Also notice these lines are repeated many times:

Guest Log: VBoxMP::DxgkDdiEscape: unsupported escape code (0x4e564441)

Why is the above line repeating continuously in the log file?

Thanks.

[Shawn]

well what do you know...the vbox.log file was above the attachment limit so I had to compress it using 7z.

[Frank Mehnert]

Regarding your concern that the password for the hard disk encryption could be included in the core dump: I can assure you that it's not the case. The hard disk encryption is either done by the Linux kernel or by a user space tool (not sure how LUKS is implemented). In the former case, the secure phrase is stored in kernel memory and in the latter case (user space tool) the secure phrase is stored in the address space of a user process (which is not the VirtualBox process of course). As you know, Linux processes are protected against each other and the kernel is protected from user space. The core dump of a process contains only information visible to the user space process, no information of the kernel and no information from other processes.

And, as a further note, we keep all core dumps we get private and delete them once the investigation of the actual problem is done.

[Shawn]

Replying to frank:

Regarding your concern that the password for the hard disk encryption could be included in the core dump: I can assure you that it's not the case. The hard disk encryption is either done by the Linux kernel or by a user space tool (not sure how LUKS is implemented). In the former case, the secure phrase is stored in kernel memory and in the latter case (user space tool) the secure phrase is stored in the address space of a user process (which is not the VirtualBox process of course). As you know, Linux processes are protected against each other and the kernel is protected from user space. The core dump of a process contains only information visible to the user space process, no information of the kernel and no information from other processes.

And, as a further note, we keep all core dumps we get private and delete them once the investigation of the actual problem is done.

Thank you for replying. I have a question though, don't we upload the core dump here in the bug tracker? Thus it is visible to all?

Also I am able to reproduce this excessive logging:

Guest Log: VBoxMP::DxgkDdiEscape: unsupported escape code (0x4e564441)

Is there instructions somewhere on how to make the core dump for Fedora 17?

Sorry for late reply. And thanks again for responding.

[misha]

Replying to shawnsumin:

Also I am able to reproduce this excessive logging:

Guest Log: VBoxMP::DxgkDdiEscape: unsupported escape code (0x4e564441)

This seems like some third-party code is making escape calls to VBox miniport video driver. Do you have some custom graphics-related software installed in the guest?

[Shawn]

Replying to misha:

Replying to shawnsumin:

Also I am able to reproduce this excessive logging:

Guest Log: VBoxMP::DxgkDdiEscape: unsupported escape code (0x4e564441)

This seems like some third-party code is making escape calls to VBox miniport video driver. Do you have some custom graphics-related software installed in the guest?

Thanks for responding.

Yes. The guest OS has Nvidia Graphics Driver. The guest was created using Disk2VHD software for Physical to Virtual migration.

[misha]

Replying to shawnsumin:

Thank you for replying. I have a question though, don't we upload the core dump here in the bug tracker? Thus it is visible to all?

You should upload it to ​ftp://ftp.oracle.com:/appsdev/incoming . This directory is write-only for public users for security reasons, so none outside Oracle can see your core dump at all.

[misha]

Replying to shawnsumin:

Yes. The guest OS has Nvidia Graphics Driver. The guest was created using Disk2VHD software for Physical to Virtual migration.

So most likely it's some NVIDIA software tries to call VBox video driver assuming it is NVidia one.
Perhaps you could try uninstalling/disabling the NVIDIA software to see if this solves the issue?

[misha]

Is there anything except the "VBoxMP::DxgkDdiEscape: unsupported escape code" warning left for this bug?
Since this warning per-se is actually caused by some third-party software doing something unexpected, I will close this record.