Resize Partitions under Windows Server 2003 - 0x00000074: BAD_SYSTEM_CONFIG_INFO

Discussions about using Windows guests in VirtualBox.
jemi
Posts: 11
Joined: 16. Jan 2018, 13:59
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Win2K3, Win7, Ubuntu

Resize Partitions under Windows Server 2003 - 0x00000074: BAD_SYSTEM_CONFIG_INFO

Post by jemi »

Hello,

I needed to resize C: drive in a Win 2003 guest (Guest A), after using

Code: Select all

VBoxManage modifyhd [path to vdi file] [dash dash]resize [size]
The extra space was adjacent to C:, and I removed paging file, as instructed by

Code: Select all

diskpart
Using

Code: Select all

diskpart
still failed, with
The volume you have selected may not be extended. Please select another volume and try again.
message.

Then I tried mounting the vdi from the problem virtual machine Guest A, and using diskpart from within another Windows 2003 guest (Guest B). Diskpart worked. However, I can no longer boot into Guest A with 0x00000074: BAD_SYSTEM_CONFIG_INFO error. Attached is the screenshot with this error.

VirtualBox 5.0.32 Mac OS X 10.9.5
Attachments
scr.png
scr.png (121.63 KiB) Viewed 4162 times
andyp73
Volunteer
Posts: 1631
Joined: 25. May 2010, 23:48
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Assorted Linux, Windows Server 2012, DOS, Windows 10, BIOS/UEFI emulation

Re: Resize Partitions under Windows Server 2003 - 0x00000074: BAD_SYSTEM_CONFIG_INFO

Post by andyp73 »

Stop error code 0x74 (BAD_SYSTEM_CONFIG_INFO) typically is due to the SYSTEM hive within the Windows registry being corrupt. I would guess that in your case either the virtual disk hasn't resized correctly or that there is something contained within the SYSTEM hive that now doesn't match your configuration.

Google throws up a number of pages that detail how you can potentially recover from this. If all else fails you could go back to the backup you took of your vdi file and go through the process again.

-Andy.
My crystal ball is currently broken. If you want assistance you are going to have to give me all of the necessary information.
Please don't ask me to do your homework for you, I have more than enough of my own things to do.
jemi
Posts: 11
Joined: 16. Jan 2018, 13:59
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Win2K3, Win7, Ubuntu

Re: Resize Partitions under Windows Server 2003 - 0x00000074: BAD_SYSTEM_CONFIG_INFO

Post by jemi »

Indeed, Google showed that 0x74 is usually mismatch in number of processors or RAM config.

I suspect that when I mounted Guest A into Guest B, Guest B's config (number of processors etc) could have affected Guest A during resize. Is this a possibility?
mpack
Site Moderator
Posts: 39156
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: Resize Partitions under Windows Server 2003 - 0x00000074: BAD_SYSTEM_CONFIG_INFO

Post by mpack »

Please give the reference to whatever advice said to remove the paging file? I don't understand what possible relevance that could have to a disk size increase. The paging file is related to RAM size, not disk space. And even when changing RAM, Windows page files are dynamic, it's not like we were talking Linux with its fixed size swap partition.

I assume you're aware that DiskPart can't be used to resize an XP/2K3 system partition while its running.

Was this Win2K3 image previously working as a VirtualBox VM? I ask because the error message indicates otherwise (the bad registry hive info is a red herring: AFAICS that advice only applies to Win10, not XP).
jemi
Posts: 11
Joined: 16. Jan 2018, 13:59
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Win2K3, Win7, Ubuntu

Re: Resize Partitions under Windows Server 2003 - 0x00000074: BAD_SYSTEM_CONFIG_INFO

Post by jemi »

mpack wrote:Please give the reference to whatever advice said to remove the paging file?
I don't have enough privileges yet to post links.

Well, when I started seeing
The volume you have selected may not be extended. Please select another volume and try again.
message I googled that. I got three possible issues:
1. The volume to be extended must be adjacent (check)
2. For Win2K3 (not R2) there is a hotfix from M$. (I have R2, so no go) (google: The DiskPart.exe utility cannot extend a logical drive in an extended partition in Windows Server 2003)
3. Pagefile cannot be located on the volume being resized (many sources) (google: The Operation Is Not Allowed on a Disk That Contains a Pagefile Volume-Explained)
mpack wrote:I assume you're aware that DiskPart can't be used to resize an XP/2K3 system partition while its running.
I was not. But after failing with 'live' resizing, googled, and found an option to mount the vdi to another Win2K3 and the rest is described in the intro.
mpack wrote:Was this Win2K3 image previously working as a VirtualBox VM?
Yes, it was.

As a side note, the only reason I needed to resized the volume is because I need to restore an SQL backup, of 2.5GB in size, which apparently expands to over 42GB, judging by SQL server's message during restore. VirtualBox does not auto resize the volume for MS SQL.
mpack
Site Moderator
Posts: 39156
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: Resize Partitions under Windows Server 2003 - 0x00000074: BAD_SYSTEM_CONFIG_INFO

Post by mpack »

jemi wrote:VirtualBox does not auto resize the volume for MS SQL.
VirtualBox does not auto-resize volumes, period.

As to the paging file issue, I suspect they're just using that as shorthand for the system drive. Basically XP doesn't let you resize a drive that's currently mounted, and you can't unmount a live system drive. I can't believe that the pagefile is the only reason for that.

Personally I would have just resized and repartitioned the drive using CloneVDI, and skip all that offline/diskpart/pagefile stuff. CloneVDI will run on an OS X host under Wine.
jemi
Posts: 11
Joined: 16. Jan 2018, 13:59
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Win2K3, Win7, Ubuntu

Re: Resize Partitions under Windows Server 2003 - 0x00000074: BAD_SYSTEM_CONFIG_INFO

Post by jemi »

mpack wrote:Personally I would have just resized and repartitioned the drive using CloneVDI
Thank you. Will try.

Just to be sure for the future: is the option to mount vdi into another similar virtual machine and using

Code: Select all

diskpart
a valid one?
mpack
Site Moderator
Posts: 39156
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: Resize Partitions under Windows Server 2003 - 0x00000074: BAD_SYSTEM_CONFIG_INFO

Post by mpack »

Yes, it's valid for repartitioning, but it's a somewhat long winded way of doing things. The preferable option IMHO would be to boot the same VM from a gparted live cd ISO (you can forget the pagefile stuff). But, that isn't necessary if you use CloneVDI: and I do recommend that you revert to the original unresized VDI and get CloneVDI to do the whole job.

Btw, can you remember what logical size the drive had before you resized it?
jemi
Posts: 11
Joined: 16. Jan 2018, 13:59
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Win2K3, Win7, Ubuntu

Re: Resize Partitions under Windows Server 2003 - 0x00000074: BAD_SYSTEM_CONFIG_INFO

Post by jemi »

mpack wrote:Btw, can you remember what logical size the drive had before you resized it?
Only ballpark figures: win was reporting 13GB in C:, Finder in Mac was reporting vdi file at 5.6GB. From within Mac I resized vdi to 50GB, then mounted vdi to another Win2K3 and extended 13GB partition to 37GB unused portion of drive C: (as reported by disk manager in win).
mpack
Site Moderator
Posts: 39156
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: Resize Partitions under Windows Server 2003 - 0x00000074: BAD_SYSTEM_CONFIG_INFO

Post by mpack »

Ok, I just wanted to make sure that the drive wasn't previously below 8GB, as enlarging the drive from <8GB to >8GB would have corrupted it and might have explained some of the problems.
jemi
Posts: 11
Joined: 16. Jan 2018, 13:59
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Win2K3, Win7, Ubuntu

Re: Resize Partitions under Windows Server 2003 - 0x00000074: BAD_SYSTEM_CONFIG_INFO

Post by jemi »

Is this below 8GB limit true for windows guests or any other OSs too? What is the recommended minimum volume size to avoid resizing problems?
mpack
Site Moderator
Posts: 39156
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: Resize Partitions under Windows Server 2003 - 0x00000074: BAD_SYSTEM_CONFIG_INFO

Post by mpack »

It applies to any drive using an MBR partition map. I gave the relevant dimensions already, so the problem does not apply to you.
jemi
Posts: 11
Joined: 16. Jan 2018, 13:59
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Win2K3, Win7, Ubuntu

Re: Resize Partitions under Windows Server 2003 - 0x00000074: BAD_SYSTEM_CONFIG_INFO

Post by jemi »

Well, setting the initial volume size when creating a VM does not seem to affect the VDI size. I re-created the win2K3R2 machine, but with drive size of 50GB. The VDI was the same 2.5GB to start with.

Is this sensible thing to do with all initial sizes, so as to avoid/minimize the need for resizing?
mpack
Site Moderator
Posts: 39156
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: Resize Partitions under Windows Server 2003 - 0x00000074: BAD_SYSTEM_CONFIG_INFO

Post by mpack »

I'm kinda losing track of what you're talking about. Nothing I've just been discussing has to do with VDI file size. I talked about drive sizes, i.e. logical capacity. Not file size.
jemi
Posts: 11
Joined: 16. Jan 2018, 13:59
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Win2K3, Win7, Ubuntu

Re: Resize Partitions under Windows Server 2003 - 0x00000074: BAD_SYSTEM_CONFIG_INFO

Post by jemi »

I am digressing from the original topic (the 0x74 error), but if you please bear with my final questions. The reason, I thought, to select low figures for disk sizes (logical) for the guest system was to conserve disk space on the host.

I have 256GB SSD drive, as you can imagine, I aim to cram as many VMs as possible without shifting them back and forth to external drives.

I thought, selecting low figures for virtual drives when they are being created would directly affect the size (lower) of VDI disks on my host's SSD. Naturally, these low figures for guest volume sizes would likely lead to the need of resizing, as in my opening case here.

So, if the logical volume sizes of guests do not directly correlate with VDI sizes on the host SSD when created (they will grow with the use, naturally), why not set the guest volume sizes to something reasonably high from the get go? Are there any pitfalls to this train of reasoning?
Post Reply