VirtualBox

Custom Query (16363 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (1816 - 1818 of 16363)

Ticket Resolution Summary Owner Reporter
#8669 duplicate 32bit color problem w/ Windows GUEST guest additions... Jesse Palser
Description

Program that has worked perfectly in previous VirtualBox versions
is now broken after 4.0.0 and is crashing (BSOD) Windows XP guest.

Problem is with Windows Guest Additions > 4.0.0
When desktop color is set to 32bit, above crash occurs,
but when desktop color is set to 24bit, above crash does NOT occur

Program is : "NeoPaint for Windows" version 4.7c
Trial Download: http://www.neosoftware.com/npwdownload.html

System is as follows:


Dell XPS 420 (Custom Modified)
Dell XPS 420 Motherboard
Intel Core2Extreme 3GHz 4 Core CPU
8GB DDR2 RAM Memory
nVidia GeForce GTS 450 1GB DDR5 PCIexpress Graphic Adapter
Creative Sound Blaster Audigy SE PCI Sound Card

VBOX : 4.0.4
HOST : Ubuntu 10.10 64bit Linux
GUEST: Windows(R) XP Professional Service Pack 3 32bit


If you need more information, just ask.
Thanks!

JeZ+Lee

#12984 obsolete [4.3.10]-Linux Host-Windows XP/7 Guest-OpenGL Problems? JeZxLee
Description

Hi,

Running current VirtualBox version 4.3.10 on a Kubuntu 14.04 64Bit fully updated Host with both a Microsoft XP Pro 32Bit SP3 Guest and a Microsoft Windows 7 Ultimate 64Bit SP1 Guest.

I've installed Windows Guest Guest Additions to both Virtual Machines. Problem in both with OpenGL hardware accelerated games. I made a post on the forums here: https://forums.virtualbox.org/viewtopic.php?f=2&t=61379

I've attached a photo to this bug report too.

This is a regression bug, as downgrading to VirtualBox version 4.1.32 solves the issue.

Jesse

#14055 duplicate UDP source port changes, breaking VPN connections Jeff Mitchell
Description

I am having a problem very similar to the one described in #6667, except that it's on OSX using official packages version 4.3.26.

After discussion of a disconnect problem I was having with the OpenVPN developers, they believed the issue could lie with the VM NAT stack. They suggested capturing traffic on the OpenVPN server and indeed, when I did so I could see that in the middle of a connection (running rsync between two VMs via the server) the UDP source port for the VPN connection suddenly changed:

...
20:46:59.274161 IP 172.19.45.154.50349 > 172.27.102.152.443: UDP, length 1445
20:46:59.274547 IP 172.19.45.154.50349 > 172.27.102.152.443: UDP, length 1445
20:46:59.274555 IP 172.19.45.154.50349 > 172.27.102.152.443: UDP, length 1445
20:46:59.276917 IP 172.19.45.154.50349 > 172.27.102.152.443: UDP, length 1445
20:46:59.277719 IP 172.19.45.154.59878 > 172.27.102.152.443: UDP, length 1445
20:46:59.277993 IP 172.19.45.154.59878 > 172.27.102.152.443: UDP, length 1445
...

When this happens, of course, the VPN software thinks the old connection has died, and eventually times out and disconnects.

At this point I can trigger the problem extremely reliably by rsyncing files over the VPN connection -- it will happen within a minute. This suggests to me that what's triggering this problem is either the total data rate back and forth through the NAT stack or some total number of packets or bytes through the NAT stack. That, or for some reason at some point the NAT stack stops correctly tracking the connection, decides that it's a new connection, and gives it a new outbound port. Just my guesses.

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy