Problem with command line

[maxhgm]

I suspect the issue may have occurred after adjusting the size of the boot partition due to a new Windows update that required more space than the default installation had left. But as I said, the only symptom was during the backup, and it was resolved by recreating the partitions and cloning the data back.

[admin]

I suspect the issue may have occurred after adjusting the size of the boot partition due to a new Windows update that required more space than the default installation had left. But as I said, the only symptom was during the backup, and it was resolved by recreating the partitions and cloning the data back.

Do you mean that the problem occurs after you have resized the boot partition? Is the boot partition you are referring to the one where the Windows folder is located? We need detailed information to try to reproduce the problem. Thanks.

[maxhgm]

Yes, I noticed that the problem started after I adjusted the system reserved partition on disk 0, but the issue also occurred in the task that backed up disk 1, so I'm not sure of the correlation. Let me try to summarize the steps.

I created 2 tasks, one for backing up the operating system (disk 0 in the image) and another for the data drive (disk 1). Disk 2 is the primary destination for the backups. In the first few months, everything was okay until the partition adjustment.

After that, either of the two tasks would generate the problem, even the one that only looked at disk 1.

After finding the message in the logs, I ran a full scandisk and found nothing.

Then I backed up the partitions of disks 0 and 1, removed the partitions via the Windows Disk Manager, recreated the partitions with the same size and type, and then restored the backup. It seems to have resolved the issue, at least for now.

The strange thing is that the backup task for disk 1 generates the error only when performing an incremental backup via scheduling.

I believe it might be difficult to reproduce, but I hope the report is helpful.

[admin]

Ok, thank you very much for the info. Were you adjusting the head or tail of the system reserved partition?

[maxhgm]

Tail, from 150 to 500 MB.

[Jim1cor13]

Are you talking about the WinRE partition that some needed to resize after January updates?

I was just wondering, as that is what it sounded like, not the windows partition, but the WinRe recovery partition.

[Froggie]

@Jim1cor13 - even after resizing the Recovery Partition (which I did), some, like myself found that the 100mB EFI (ESP) partition only had less than 2mB left... this scared me a bit.  I had no warnings but decided to up that partition by an additional 100mB (200mB total)... just in case.  I have no idea how it became so crowded in that 100mB DEFAULT space.

When looking inside the EFI partition, I see a growth, over the months (since the build July 2023) of BCD(<some sort of ID>) .TM.blf files and .regtrans-ms files.  This is an HP machine so I have no idea what that growth is.  I have made BCD changes over the months, but on no other machine have I seen these types of file growth.  I'm guessing I could get rid of most of them but I'd like to know what they are first 

[Froggie]

Turns out they are REGISTRY change files and BCD Edit change files.  Problem is LIVE Windows won't let you mount the EFI partition so it can be edited... at least not for the general Admin user.  I then loaded my favorite WinPE with the tools I need... even then it wouldn't let me mount the EFI partition with a drive letter.  I then used a partition tool to change the basic ID of the EFI partition to a basic DATA partition, after that I was able to mount that partition with a letter for editing.  I went into the partition and carefully removed all those old (2023) files (mentioned above), dismounted the partition, reset its ID back to EFI then exited.  ReBOOTed the System and all is OK and most of that extra storage in the now 200mB EFI partition was gone.

On older Legacy-MBR Systems, that stuff is either in the MSR partition (if you have one) or located in the OS partition.  Both of those are usually larger than the 100mB DEFAULT EFI partition generated on UEFI-GPT Systems.  I'm not sure what happens if you need more space than what is available when an edit is being done by the System during an EFI update... I don't really wanna find out  . I do mess with my BCD and REGISTRY quite often... I guess I need to be concerned in this area.

Hasleo Devs... any great and glorious knowlege to offer us in this area? 

[Jim1cor13]

@Jim1cor13 - even after resizing the Recovery Partition (which I did), some, like myself found that the 100mB EFI (ESP) partition only had less than 2mB left... this scared me a bit.  I had no warnings but decided to up that partition by an additional 100mB (200mB total)... just in case.  I have no idea how it became so crowded in that 100mB DEFAULT space.

When looking inside the EFI partition, I see a growth, over the months (since the build July 2023) of BCD(<some sort of ID>) .TM.blf files and .regtrans-ms files.  This is an HP machine so I have no idea what that growth is.  I have made BCD changes over the months, but on no other machine have I seen these types of file growth.  I'm guessing I could get rid of most of them but I'd like to know what they are first 

Hi Froggie

Interesting. I resized my WinRe partition last year I think around July I think, up to 1.1GB in size. I used partition wizard at the time. It "worked" after that but when the MS update came out to update the winre.wim in that partition it failed. I knew there was more than enough size, so I disabled it using reagentc, then re-enabled it. That fixed my issue with the MS update in January, and it finally updated fine. I think it was because my disabling and then enabling gave it a new Boot Configuration Data (BCD) identifier.

I think that fixed the recovery partition and allowed it to be updated. I think there was a problem with it since I resized it for some reason, even though it "worked".

I just checked my EFI partition, I opened up a Hasleo disk/partition image and saw the EFI is 200MB with 172.2MB free. But I do not mess with BCDedit. I had no idea that it would affect the used space of your EFI like it did. Never heard of that, hopefully the dev's can explain it.

When I changed from MBR to UEFI GPT, I followed Macrium instructions, created the EFI partition, and the raw MSR partition of 128MB, not formatted, then restored my windows C part and the recovery part at the time. I had to shrink my OS part a bit to fit the old WinRe at the end of the drive.

Then ran the Macrium I think fix boot problems, and it found the windows installation and updated the boot manager. I went into BIOS and change to UEFI non-legacy, it will only boot UEFI drives. That seemed to be fine, but I had to mess with the recovery part after going to UEFI GPT, messing with it using reagentc and got that working.

First time I ever did something like that, I always used MBR disk. I'm glad I changed to UEFI, but MBR is fine, it is all I ever used up until I decided to change it.

[admin]

Turns out they are REGISTRY change files and BCD Edit change files.  Problem is LIVE Windows won't let you mount the EFI partition so it can be edited... at least not for the general Admin user.  I then loaded my favorite WinPE with the tools I need... even then it wouldn't let me mount the EFI partition with a drive letter.  I then used a partition tool to change the basic ID of the EFI partition to a basic DATA partition, after that I was able to mount that partition with a letter for editing.  I went into the partition and carefully removed all those old (2023) files (mentioned above), dismounted the partition, reset its ID back to EFI then exited.  ReBOOTed the System and all is OK and most of that extra storage in the now 200mB EFI partition was gone.

On older Legacy-MBR Systems, that stuff is either in the MSR partition (if you have one) or located in the OS partition.  Both of those are usually larger than the 100mB DEFAULT EFI partition generated on UEFI-GPT Systems.  I'm not sure what happens if you need more space than what is available when an edit is being done by the System during an EFI update... I don't really wanna find out  .  I do mess with my BCD and REGISTRY quite often... I guess I need to be concerned in this area.

Hasleo Devs... any great and glorious knowlege to offer us in this area? 

We tested with a simple BCD and determined that the files were generated by an ID stored in the BCD file, and that loading and unloading the BCD file multiple times would not result in more files, even if the BCD file was copied to a different location. 


Yet on one of my computers that I've had for years, there are no .TM.blf and .regtrans-ms files generated based on multiple IDs.


Did you regenerate the BCD file for that partition? Or has some other program changed the ID stored in this BCD?