Attila Kovacs

Ah I see, well, I tried to convert some pdb's to yaml but after it failed on every pdb's I've found I got upset and forensic wiped it from my ssd 😉 I've no idea how good this yaml converter is but after that I've doubts.

0001:00401000 0190D0A0H .text CODE why is it .text? anyway 0001:0151D808 unit.frmxyz.BtnNewClick 0151D808 + 00401000 is the actual address (400000 is the image base and 1000 is the section alignment)

to the base address I can check it. Which section should I look in the map?

does pdb2yaml gives the same yaml back?

Yeah the GUID match can be done on the PDB, at least I've seen tools for do that yeah, when the pdb works yes, but untested?

@Anders Melander Maybe this could inject it, just to test how the pdb performs http://www.pe-explorer.com/peexplorer-tour-section-editor.htm

I'd still use jobs for creating compressed backups and copy them to another location. I don't know how this batchmove works but I'm sure it won't lock anything nor will it transfer transaction logs -if any-, so high chances that the data won't stay consistent.

This is it.

Is it tested now? Btw. interestingly WM_NCDESTROY's are still coming for all of the windows. The chained list theory fails? also as switching the freeing order of the scrollbars (vertical,horizontal to horizontal,vertical) free's the horizontal fine, then vertical becomes the next in the z-order and freeing it breaks the message chain again. If it has actually something to do with the Z-Order. Edit: Just to make sure, I've compiled the testapp with D2007 and D5, and run it even on XP, it's always the same.

I can't test it as ForceQueue is not present in Berlin, but in theory looks good.

Destroying a window from a different thread? Does it work?

this is really below every standard but what about if not (csDestroying in Application.ComponentState) then it works fine and I can't see any just as simple solution

I'm currently here

Buhh. Well, this is a new problem. Still, there is no legitimate reason to call consecutive DestroyWindows.

Aha! Now I'm getting closer. Have to fire up a new form to check.

in class destructor TStyleEngine.Destroy; FreeAndNil(FControls); will free all remaining StyleHooks. Who cares by who or when will it be free'd on closing the application?

The above non-quality? "fix" resolves the problem calling nested DestroyWindow and thus stopping WM_DESTROY propagation. The application does not yield any new leaks so I don't understand your point, what am I missing?

Ok, i see what you are saying, the remove should be evt. called, free() not. But the dictionary will be free'd even if it's not empty. So, I guess doesn't matter. Edit: no, calling remove results in other leaks. It was just fine that way.

Exactly this is the problem. That is what I wanted to avoid. Those are parented to the parent of the ListView and will be destroyed by the window manager.

stylehooks are no windowed controls like the scrollbar

just copy the vcl sources to your project dir and alter them it works evt. could be further higher in the callstack

if not (csDestroying in Control.ComponentState) then begin FControls.Items[Control].Free; FControls.Remove(Control); end; in class procedure TStyleEngine.DoRemoveControl(Control: TWinControl); cut nested calls to DestroyWindow

Looks like on RecreateWnd it's necessary to free the two themed scrollbars, but at the moment the window manager kicks in with destroying all controls, it becomes a problem. I've tested on W7, it's the same. I like the workaround to eliminate the message broadcasting like @pyscripter suggested as this seems to have more advantage. Otherwise, creating a transparent container between TListView and its Parent could eventually solve the issue. I'd say give it as-is to Emba, let's see how they think about it, maybe they have more comments in the VCL.

@balabuev Nice work! I replaced the buttons with TListViews with some Nodes and the leak appears. Do we know where the dog is buried or is it time to ask Mr. Chen? Looks like it's only happening if we are destroying the next window in the order, then it's stops all the propagation of WM_DESTROY's, like if there were an exception in the window manager. If we skip one control it's fine again (4 buttons, freeing Nr. 3 on Tag1, not Nr.2).

@emailx45 does not work with code or am I dumb