Please attach your registrymodifications.xcu - not enough to just say it's large. NEEDINFO. Once you attach set to UNCONFIRMED.

(In reply to Joel Madero from comment #1)
> Please attach your registrymodifications.xcu - not enough to just say it's
> large. NEEDINFO. Once you attach set to UNCONFIRMED.

I can't: "File size limit: 10000 KB."

Anyway, I've tried zipping it and found that it didn't shrink as much as I expected: 10.6Mb. (Still above limit) So, I took a look inside and found that most of it consists of machine code. To give you an idea:

iVBORw0KGgoAAAANSUhEUgAAALUAAAEACAIAAAB6QaCMAACABElEQVR4nO39d5Ak13UvDN70mVVZ3ps21d5O2zE9vsdgYAkSoGhESZTXe29fxG7E7h8bsf9vxMZufBHf7tvd7/tC760eJT1JNCIJkrADYAZjMd63966qy/v0uTczq2p6BoMWBugRMWQdIHqqsm5m3rz35Lm/c+4xuCzLoE51+hzCf9sdqNPXmur8UaftqM4fddqO6vxRp+2ozh912o7q/FGn7ajOH3Xajur8UaftqM4fddqO6vxRp+2ozh912o7q

This preceded by
<prop oor:name="Filter" oor:op="fuse"><value>writer8</value></prop><prop oor:name="Password" oor:op="fuse"><value></value></prop><prop oor:name="Thumbnail" oor:op="fuse"><value>

The gibberish takes up more than 95% of the file.

That "gibberish" are the binary coded thumbnails of the start center. Those belong to the history. The file registrymodifications.xcu should become much smaller, if you use "Clear resent documents" in Drop-down.list "Recent Files" in Startcenter. Make a copy of the file registrymodifications.xcu before trying it.

There exist already bug 99176 with the request of storing the history besides the registrymodifications.xcu.

If you can confirm, that this is the issue with your file too, I suggest to close this issue as duplicate of bug 99716.

I confirm it's the same issue. Thanks, Regina.

*** This bug has been marked as a duplicate of bug 99716 ***

I would like to keep this issue open independently from bug 99716 ("RFE: store Recent Documents apart from registrymodifications.xcu").  Whatever the outcome of that RFE, my understanding of the current situation is that the registrymodification.xcu's /org.openoffice.Office.Histories/Histories/['PickList'] (storing information about recently opened files, among them large "Thumbnail" strings) keeps ever-growing.  The only way to remove elements again, from looking at the code, appears to be to manually remove them (call to SvtHistoryOptions::DeleteItem in RecentDocsViewItem::MouseButtonUp, sfx2/source/control/recentdocsviewitem.cxx).  Designing the "recent documents" user interface in a way that stores an ever-growing amount of information is obviously a bug.

Anybody know why this bug's "Version (earliest affected)" field is set to "3.3.0 release"?  It is not clear from comment 0 (apart from a vague "I believe this has been so since a long time ago"), and <https://bugs.documentfoundation.org/show_activity.cgi?id=103445> doesn't show it has been changed afterwards.

Stephan, do you happen to have installed History Master (extension) or have set a high list size, like say 50?

(In reply to Stephan Bergmann from comment #7)
> Anybody know why this bug's "Version (earliest affected)" field is set to
> "3.3.0 release"?  It is not clear from comment 0 (apart from a vague "I
> believe this has been so since a long time ago"), and
> <https://bugs.documentfoundation.org/show_activity.cgi?id=103445> doesn't
> show it has been changed afterwards.

I did that, assuming this has been be so all along and seeing that as the earliest version I can specify. I didn't scroll down (as I did just now) to see other options. Then again, I don't know which to specify anyway. Please change as you deem fit.

(In reply to Kumāra from comment #8)
> Stephan, do you happen to have installed History Master (extension) or have
> set a high list size, like say 50?

Neither.  And I did not myself reproduce the claims from comment 0.  From the comments, I (wrongly?) assumed that the problem is an ever-growing amount of /org.openoffice.Office.Histories/Histories/['PickList'] entries, and inspecting the code (quickly) seemed to confirm that assumption (as the only way in the code to ever remove anything from those entries again appears to be as described in comment 6).  However, I will need to look more closely.

(In reply to Kumāra from comment #9)
> (In reply to Stephan Bergmann from comment #7)
> > Anybody know why this bug's "Version (earliest affected)" field is set to
> > "3.3.0 release"?  It is not clear from comment 0 (apart from a vague "I
> > believe this has been so since a long time ago"), and
> > <https://bugs.documentfoundation.org/show_activity.cgi?id=103445> doesn't
> > show it has been changed afterwards.
> 
> I did that, assuming this has been be so all along and seeing that as the
> earliest version I can specify. I didn't scroll down (as I did just now) to
> see other options. Then again, I don't know which to specify anyway. Please
> change as you deem fit.

Setting to "unspecified" then.

(In reply to Stephan Bergmann from comment #10)
> (In reply to Kumāra from comment #8)
> > Stephan, do you happen to have installed History Master (extension) or have
> > set a high list size, like say 50?
> 
> Neither.  And I did not myself reproduce the claims from comment 0.  From
> the comments, I (wrongly?) assumed that the problem is an ever-growing
> amount of /org.openoffice.Office.Histories/Histories/['PickList'] entries,
> and inspecting the code (quickly) seemed to confirm that assumption (as the
> only way in the code to ever remove anything from those entries again
> appears to be as described in comment 6).  However, I will need to look more
> closely.

Indeed, my assumption from comment 6 was wrong.  Looking closer, the list is capped at (the default value of) 25, and does not cause registrymodifications.xcu to grow without bounds.  Sorry for the noise.

There is no information provided as to the exact content of the "bloating" registrymodifications.xcu, so setting back to duplicate for now.  (You can try attaching it after compressing it, or sending it to me directly.)

*** This bug has been marked as a duplicate of bug 99716 ***

Stephan, it's partly the fault of my misleading bug summary. Hope the new one is more accurate.