Hi,
I was hoping someone might have some ideas on how I can hack around a problem I'm having with the auto-complete feature of the ComboBox.
I have a data entry application that uses a pair of ComboBoxes on the main entry screen. These are configured to use the Suggest Append auto-complete feature with the List Items as the data source.
Functionally, it works great and really helps speed up the entry process.
However it appears that when my users are pounding in the data, the auto-complete feature leaks memory and/or threads and eventually takes the application down.
I fumbled around for some time with WinDbg and SOS before I figured out the problem.
When I do a !DumpHeap –stat, I find 1325 objects of type System.Windows. Forms.ComboBox+ ACNativeWindow
When I do a !GCRoot on one of these I find:
DOMAIN(00159520 ):HANDLE(Pinned ):9413e8:Root:0 22c4260(System. Object[])->
01469b7c(System .Collections.Ha shtable)->
01503a64(System .Collections.Ha shtable+bucket[])
It appears when these auto-complete threads are spawned they are added to a static hashtable inside the ComboBox+ACNati veWindow class. Under certain conditions, these don’t get released and cause the resource leak.
I reported the problem to Microsoft last spring, but my ticket was “Closed Unresolved” because they said that they were focusing on WinFX instead.
I’ve tried:
Explicit garbage collection
Explicit form/control creation/disposal
Manual loading of the list and loading via data binding
And finally manual flushing of the internal hashtable using reflection
This last one changes the !GCRoot from Pinned to WeakLn, but seems to aggravate the thread leak (79 background threads in one dump) and still doesn't release memory.
Anyone have any suggestions (other than throwing out the auto-complete)?
I was hoping someone might have some ideas on how I can hack around a problem I'm having with the auto-complete feature of the ComboBox.
I have a data entry application that uses a pair of ComboBoxes on the main entry screen. These are configured to use the Suggest Append auto-complete feature with the List Items as the data source.
Functionally, it works great and really helps speed up the entry process.
However it appears that when my users are pounding in the data, the auto-complete feature leaks memory and/or threads and eventually takes the application down.
I fumbled around for some time with WinDbg and SOS before I figured out the problem.
When I do a !DumpHeap –stat, I find 1325 objects of type System.Windows. Forms.ComboBox+ ACNativeWindow
When I do a !GCRoot on one of these I find:
DOMAIN(00159520 ):HANDLE(Pinned ):9413e8:Root:0 22c4260(System. Object[])->
01469b7c(System .Collections.Ha shtable)->
01503a64(System .Collections.Ha shtable+bucket[])
It appears when these auto-complete threads are spawned they are added to a static hashtable inside the ComboBox+ACNati veWindow class. Under certain conditions, these don’t get released and cause the resource leak.
I reported the problem to Microsoft last spring, but my ticket was “Closed Unresolved” because they said that they were focusing on WinFX instead.
I’ve tried:
Explicit garbage collection
Explicit form/control creation/disposal
Manual loading of the list and loading via data binding
And finally manual flushing of the internal hashtable using reflection
This last one changes the !GCRoot from Pinned to WeakLn, but seems to aggravate the thread leak (79 background threads in one dump) and still doesn't release memory.
Anyone have any suggestions (other than throwing out the auto-complete)?
Comment