VirtualBox

Ticket #10698 (closed defect: wontfix)

Opened 22 months ago

Last modified 6 months ago

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

Reported by: shawnsumin Owned by:
Priority: major Component: 3D support
Version: VirtualBox 4.1.18 Keywords: crash, 3d, nvidia
Cc: shawn.sumin@… Guest type: Windows
Host type: Linux

Description

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.

Attachments

VBox.log.7z Download (29.4 KB) - added by shawnsumin 22 months ago.

Change History

Changed 22 months ago by shawnsumin

comment:1 Changed 22 months ago by shawnsumin

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

comment:2 follow-up: ↓ 3 Changed 22 months ago by 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.

comment:3 in reply to: ↑ 2 ; follow-ups: ↓ 4 ↓ 6 Changed 22 months ago by shawnsumin

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.

comment:4 in reply to: ↑ 3 ; follow-up: ↓ 5 Changed 22 months ago by 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?

comment:5 in reply to: ↑ 4 ; follow-up: ↓ 7 Changed 22 months ago by shawnsumin

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.

comment:6 in reply to: ↑ 3 Changed 22 months ago by 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.

comment:7 in reply to: ↑ 5 Changed 22 months ago by 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?

comment:8 Changed 6 months ago by misha

  • Status changed from new to closed
  • Resolution set to wontfix

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.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use