The "default transaction resource manager" issue revisited

https://www.wilderssecurity.com/showthread.php?t=175737

I triggered this problem in *Vista SP1* (where it's supposed to be fixed) by using the latest DD to resize a couple data partitions. Event Viewer now always reads this:

"The default transaction resource manager on volume E: encountered a non-retryable error and could not start. The data contains the error code."

Per the thread, I've run the fsutil resource etc command against both my Windows partition and volume E, and rebooted, but it changed nothing.

Any ideas?

 

rseiler:

I would try the following, in this order:

1. Run chkdsk E: to see if there is any file system corruption on your E: data partition. If there is then run chkdsk /f E: to repair.
2. If you have room, copy all of the files from E: to temporary storage. Use Vista Disk Management to reformat the E: partition. Then copy your files back.
3. If the problem persists, put a paging file on your E: drive to prevent TI from attempting to lock the drive. I remember using this as a temporary workaround before Vista SP1 fixed the problem.

 

Hi Mark. Chkdsk didn't report anything, but before blowing away the partition and starting over, I increased its size a bit so that there would be more free space (it was quite low, since it's a very static drive that's not going to see any increase). Lo and behold, that did the trick, since my next reboot didn't show the error.

So I guess I found a new way of triggering the problem, possibly unrelated to the other ways, I'm not sure.

However, I did realize that since using DD, I had another issue people had already found, so I've added onto this thread:
https://www.wilderssecurity.com/showthread.php?t=199565

 

Glad you got things working again.

I think the issues referenced in the thread are endemic to the nature of Windows. If your resize operation moved the starting sector of the partition then the partition will have a new and different partition ID. Thus, Vista will see a new volume added, and the old one that contained restore points is now orphaned since its partition ID no longer exists. The restore points are lost since they reference changes to absolute sectors, and you've moved things around. I'm not sure that DD could work around this.

 

That makes sense, though I wonder if Vista's own disk management program does either when using it to resize a partition?

If it doesn't, it may be because MS is working with inside knowledge, or possibly because its shrink/expand capabilities don't go as far as DD's. That is, if I had used DD to merely do a simple shrink/expand, one that Disk Management is also capable of (and this one wasn't, for whatever reason), I wonder if I'd have seen the problem?

 

Disk Management has "inside knowledge" like you say, so it will normally take care of these kinds of details. You also could have avoided the problem if you only moved the ending sector of the partition because the partition ID is generated using the Disk ID and the starting sector of the partition. Whenever you modify the starting sector then you will run into this.

 

I'll definitely keep that in mind. In this case, since I was shrinking the partition to the "left" of the one I wanted to expand, the one I expanded inevitably would have its starting sector moved -- unless I'm thinking about this in the wrong way.

I initially did try doing this in Disk Manager, but the partition I wanted to reduce would only go down about half as far as I wanted it to. I eventually found the reason for it in the excellent "Vista Annoyances" book, which said that "Windows doesn’t necessarily store all your data at the beginning of a partition, but rather scatters it around to help reduce fragmentation. As a result, there may be some data toward the end, serving as a barrier to prevent Disk Management from shrinking your drive past that point."

The solution was to run a very time-consuming defrag -w, and even then it wasn't guaranteed to work. The next recommendation was DD.