Opened 8 years ago
Last modified 6 years ago
#16361 new defect
Windows XP guest keeps crashing in recent releases
| Reported by: | Rafcio | Owned by: | |
|---|---|---|---|
| Component: | other | Version: | VirtualBox 5.1.12 |
| Keywords: | Cc: | ||
| Guest type: | Windows | Host type: | Windows |
Description
I can't tell exactly when this started, but the XP guest was very stable in versions 4.3 and 5.0 (at least the early ones). The guest keeps crashing now at random intervals, so the regression could have been introduced with version 5.1. I didn't upgrade to version 5.1 from 5.0 right away as there were audio issues initially, and when the audio was "fixed" the 5.1.x version was already "broken" for that XP client. That XP client heavily uses network adapter, but I'm not sure if that's a contributing factor or not. The host is Windows 10 version 1607.
BTW, this is not related to this issue, but I want to mention this for clarity. Bug #16221 did not concern Linux client only. I had major issues with transmit pauses (between few seconds to few minutes) on Windows 10 host. So the bug affected Windows also and also host network interface. It seems to be fixed now, so I'm not going to open a new ticket unless I notice a troubling network interface behavior, but the comment that bug #16221 was concerning Linux only (wrong) client (wrong again) troubles me that there could be things not fixed correctly. Like I said, no issue with pausing after upgrading to 5.1.12.
Attachments (9)
Change History (22)
by , 8 years ago
comment:1 by , 8 years ago
I have more logs to add and I also noticed that this particular guest is likely to crash when TeamViewer session is being initiated to the host computer (Windows 10) and the host computer is the controlled machine.
comment:2 by , 8 years ago
Please define "guest crash" with your Windows XP guest. The log files show that the heartbeet timer no longer ticks. Is the guest just unresponsive or is there some BSOD?
What happens if you disable 3D in the VM settings?
comment:3 by , 8 years ago
It's BSOD. It's not really blue, but black and the error code is 8E if I remember correctly. I can get a screen shot if that would help.
comment:4 by , 7 years ago
Actually, the screen is blue (not black). Most often the screen saver image is frozen on the screen with a red bar at the top, so it doesn't show a BSOD, however when power down of the VM is selected, then the screen is repainted showing a "black" screen of death. It turns blue though when power down is cancelled. Most of the time the BSOD doesn't list a specific driver, just code 8E (I will attach an image), but today there was a driver listed, so I took a screen shot and will upload that too.
comment:5 by , 7 years ago
Here is a typical scenario. Well, almost. The guest has a screen saver image frozen with a red bar at the top, which I captured and will upload. When I choose to power down the VM the screen is repainted revealing a black screen of death (which will turn blue if power down is cancelled). In this next image the screen is not typical, because typically there is no message IRQL_NOT... or any driver indicted. It's unspecified 8E crash that I've specified earlier.
comment:6 by , 7 years ago
This bug seems to be introduced in 5.1.x. Not having any progress on the resolution I decided to go back to version 5.0.26 (the last one before upgrading to 5.1.x) and the issue went away. Not only this one was fixed, but also 16419. That was months ago, but I forgot to update the ticket. Recently I installed 5.0.40 and it's still very solid. Obviously 5.1 is really bad direction. A lot that was working previously got broken.
comment:7 by , 7 years ago
You seek for help but don't answer basic questions. It's obviously hard to help in such cases. In comment:2 I asked you what happens if you disable 3D in the VM settings but I didn't see a an answer to my question.
comment:8 by , 7 years ago
I'm sorry, I must have missed that. 3D acceleration wasn't enabled (in fact never been on this particular client) and I thought that this should be indicated in the log file that has been attached. Also, I assume that if I don't mention any client changes, the only thing that changes are the host software releases, especially if I make a comparison to another version.
comment:9 by , 7 years ago
One other thing that I should have mentioned is that my suspicion is that the cause of the BSOD was related to network issue (bug 16419 mentioned previously) and not to graphics. I believe that one of the images attached had BSOD mentioning a driver from a network protocol stack.
comment:10 by , 7 years ago
The background of my question was not to find out if you enabled 3D in the VM settings when it was disabled before, well, at least not primarily, but rather to find out if the suspicious code location can be narrowed down.
You might be aware that there are thousands tickets open and we have only limited resources for this kind of support. When reading a ticket I usually have suspicions about the problem and try to eliminate possible reasons by asking questions. I'm sure you will see this procedure in other bugtrackers as well.
I'm not aware of similar problems. I see that 3D is disabled for your VM but for some reason 2D video acceleration is enabled. Well, this shouldn't matter but it would still make sense to disable this setting. Or is the 2D video acceleration checkbox activated but disabled (not changeable)?
There is one change between 5.0.x and 5.1.x which could be related to your problem: The APIC and I/O-APIC code was completely rewritten.
How easy is it for you to reproduce this BSOD, how long does it take? Did you ever try to reduce the number of VCPUs from 2 to 1 and were you able to reproduce the BSOD in that case?
comment:11 by , 7 years ago
In addition to reducing the VCPU number from 2 to 1 and checking if the BSOD still happens it would be really interesting to find the exact VBox version when this problem started. You say that this does not happen in 5.0.40 but the exact 5.1.x version when this started is even more important.
comment:12 by , 7 years ago
That's going to be hard. It's a "production" machine. There is a mail server for my personal domain running in one of the VMs. I can't really afford down time of that box. And the network interfaces (not just one) pauses (bug 16419) and this issue don't just happen immediately. There is no scenario to recreate the issue on demand. For the network pauses it takes many hours of the host uptime to happen and for the XP guest to crash it even can take days. How does the CPU count in the VM can impact the host machine? Again, the network pauses happen for the host interfaces, not in the guests (at least I haven't noticed). There must be something in the network driver in the bridging code that does that. That should have nothing to do with APIC emulation.
comment:13 by , 6 years ago
Sorry for the long delay. I've found the workaround for one issue, but I can't nail down the other one precisely. So, for this one where XP client crashes the bug was introduced in 5.0. In 4.3.30 it was stable with 2 CPUs, but starting with 5.0 it crashes (eventually) with multiple CPUs. When I reduced the number of CPUs to 1 the crashes stopped. I've to mention that the client uses network heavily (running P2P sharing application), so this may be the reason why the crashes occur in network protocol driver (if I can tell that from the crash screen).
Log