Xander here on the forums unfortunately ran across a data loss issue with certain definition files for dUninstaller. Not sure why I'm not locating this thread or report at the moment, probably staring right at it or have it open in another tab even. Regardless, let me go over some facts:
1. It is currently fixed (in code) and will be soon released as v3.7.8 (or maybe a little higher, depends on testing.)
2. The issue (data loss) ONLY occurs when data is saved to disk from the dUninstaller definition editor in the user interface.
3. The issue ONLY occurs with the FILE/REGISTRY DELETE DEFS, it does NOT occur with the standard dUninstaller application uninstall definitions.
4. It does affect d7II/dUninstaller functionality as well, where the exact same issue has been discovered within its dUninstaller def editor UI, (which is also fixed and to be released as v3.5.56) although this issue does NOT affect any other d7II related definition files nor the merge definition process.
Specifics and Background:
These particular definitions (with no other real automated entry introduced) are manual entry definitions, and as such a free form edit style multi-line textbox control was used for loading/editing/saving the definitions for the easiest manual entry. The default textbox control provided by Microsoft with the programming language IDE was used for this task, as the .dll housing the textbox control already exists in every version of Windows -- you can see where this is going right? Just a primer, the textbox "control" is an object that I put the data into after reading it from a file, and that control displays it to you as a user interface/editor (a simple white box) on a "form" or application window of the User Interface. Other such "controls" exist like "command" push-buttons, checkboxes, radio buttons, listboxes, treeview (node style, even "Windows Explorer" style) windows, statusbars, progress bars, etc. etc. Many software developers don't write their own controls, but use those built into the language or OS, or even purchase them from 3rd party software developers (which I have done with the "codejock" .dll file you will notice with dUninstaller.exe)
Back to the issue, which occurs when data (a string of text in this case) is loaded from a file, is being added to the textbox control, where it simply stops adding data beyond a certain size definition file. The problem being that while the textbox control in use, the Microsoft one technically supports strings of at least 2GB in size (a different limitation by the language I use, but I know you don't have definition files that large) however the standard method the language actually provides to add data to the control, when in "multi-line" format, tops out at 64KB!!! Kinda disappointed they would provide a control that ships with the language/IDE with a certain capability, yet the command to add data to it caps its usefulness at a fraction of the capacity. I discovered a work-around, to send data to the textbox by using Windows subsystems almost as if you were sending data to a completely different process/app. To me that was taking the long way out. As it turns out though, a textbox control exists in the codejock dll I've already switched some other things over to from the default MS provided controls, and naturally the 3rd party codejock textbox control doesn't have this limitation with adding data. In short, this update is mostly all about dropping a different textbox control which existed in a 3rd party DLL (not one within Windows itself) on a form, and giving it the same object name, if that makes sense to you.
Note that while I will be releasing the fix for this now, expect another update to come soon after for definition compatibility with new d7II definition formats, and maybe to bring in some newer code being developed now for d7II for various core functions.