Windows 10.0.17763 (1809) TextBox.Text set Memory Leak RRS feed

  • Pergunta

  • I have detected an extreme memory leak condition when using the set TextBox.Text property with MultiLine set to true in a C# application running on Windows 10.0.17763 (1809 update).

    This has been causing crashes to desktop on my client systems for the last month where a communications logging text box would fail following a 20% purge operation.

    Steps to replicate the issue:
     - Generate a WinForm application with a TextBox set to MultiLine = true.
     - Set the Text property to a string containing "\r\n" (i.e "a\r\n")
     - Set the Text property to a string ending "\r" (i.e "a\r")

    The application WorkingSet will ramp quickly to around 1GB and Commit to 1.2 to 2GB for around 30 to 60s.  Following this, the app will recover, WorkingSet will reduce, but Commit memory remains allocated.  Following2 or 3 instances of this issue, the app will crash to desktop, usually throwing a Stack Overflow exception.

    A toggle of the MultiLine property between Text set operations appears to rectify this issue.

    This cannot be replicated on any non-1809 updated machines.

    Does the TextBox now cache the line feed method that it is first used with and then attempt to look for this if it is later updated with an incompatible one?  i.e continue searching the heap for the missing "\n"?

    private void breakLogButton_Click(object sender, EventArgs e)
    	logTextBox.Text = "a\r\n";
    	if (clearBeforeSetCheckBox.Checked)
    		// No effect
    	if (resetMultiLineModeCheckBox.Checked)
    		// This will rectify the issue
    		logTextBox.Multiline = false;
    		logTextBox.Multiline = true;
    	logTextBox.Text = "a\r"; // Provided MultiLine has not been toggled, application will lock here for 30 to 60s

    • Movido CoolDadTx quinta-feira, 6 de dezembro de 2018 14:39 Winforms related
    quinta-feira, 6 de dezembro de 2018 14:05

Todas as Respostas

  • Personally I would submit an issue via the chatting person button at the right top of Visual Studio.

    I see no issues with Text property e.g.

    Editor("System.ComponentModel.Design.MultilineStringEditor, " + AssemblyRef.SystemDesign, typeof(UITypeEditor))
    public override string Text {
        get {
            return base.Text;
        set {
            if (value != base.Text) {
                base.Text = value;
                if (IsHandleCreated) {
                    // clear the modified flag
                    SendMessage(NativeMethods.EM_SETMODIFY, 0, 0);

    Same goes for Lines which uses a StringBuilder.

    Editor("System.Windows.Forms.Design.StringArrayEditor, " + AssemblyRef.SystemDesign, typeof(UITypeEditor))
    public string[] Lines {
        get {
            string text = Text;
            ArrayList list = new ArrayList();
            int lineStart = 0;
            while (lineStart < text.Length) {
                int lineEnd = lineStart;
                for (; lineEnd < text.Length; lineEnd++) {
                    char c = text[lineEnd];
                    if (c == '\r' || c == '\n')
                string line = text.Substring(lineStart, lineEnd - lineStart);
                // Treat "\r", "\r\n", and "\n" as new lines
                if (lineEnd < text.Length && text[lineEnd] == '\r')
                if (lineEnd < text.Length && text[lineEnd] == '\n')
                lineStart = lineEnd;
            // Corner case -- last character in Text is a new line; need to add blank line to list
            if (text.Length > 0 && (text[text.Length - 1] == '\r' || text[text.Length - 1] == '\n'))
            return(string[]) list.ToArray(typeof(string));
            SuppressMessage("Microsoft.Globalization", "CA1303:DoNotPassLiteralsAsLocalizedParameters") // We append a new line to the Text property.
                                                                                                        // Don't localize the new line character.
        set {
            //unparse this string list...
            if (value != null && value.Length > 0) {
                // Work Item #40689:
                // Using a StringBuilder instead of a String
                // speeds things up approx 150 times
                StringBuilder text = new StringBuilder(value[0]);
                for (int i=1; i < value.Length; ++i) {
                Text = text.ToString();
            else {
                Text = "";

    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites

    sexta-feira, 7 de dezembro de 2018 00:13
  • Thanks, yes, I agree, the source for the properties themselves don't appear to have changed or indicate anything that could go wrong.  In my opinion it's pointing towards a memory management change that is taking place in the updated version of Windows, or something to do with the rendering of the text in the control following on from the SendMessage call.

    I have already posted the same question to the Visual Studio - Report a Problem tool and awaiting a reply.

    sexta-feira, 7 de dezembro de 2018 08:43
  • Hi,

    Is your problem solved? If so, please post "Mark as answer" to the appropriate answer , so that it will help other members to find solution quickly if they faces similar issue.



    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact

    segunda-feira, 7 de janeiro de 2019 03:31
  • The issue is still "Under Investigation" on the Visual Studio Developers Community page and has been for around a month now.  Still no feedback, so issue is still open.
    segunda-feira, 14 de janeiro de 2019 15:18
  • The problem can be observed in desktop programs made in C++ too. (SetDlgItemText function and alternatives hang). Therefore, it seems to be a problem of system Edit control.

    segunda-feira, 14 de janeiro de 2019 17:26
  • Fair enough, I will take your comments on the format of my bug reports on board.

    The fact that nobody else using 1809 has been able to replicate the same problem with the same code surely shows a significant issue in your logic. I noted that Kareninstructor's post states: "I see no issues with Text property..." Back to the example of providing technical support services: If I (a common MSDN User) can't replicate it and Kareninstructor (an MSDN Moderator with a fantastic track record for accurate and complete answer content) can't replicate it or spot a problem in the underlying source, then it isn't a problem in the underlying source.

    I'm sorry that you haven't been able to replicate the issue.  I see it on every single Windows PC running Windows 10 1809 update, and not on any machines running Windows 10 1803.  The specs of the machine range from Asus nettops with 1GB RAM and a Celeron CPU to Dell laptops with 16GB RAM and i7 CPUs, so doesn't seem to have any hardware dependency.  Karen also didn't indicate that she was unable to replicate the issue, merely that the framework code for the Text property had not changed.  This is fine, but there is still a problem.

    A new investigation taking that variable into account turned up a problem in the way I was handling some variables which passed from Object A into Object B and then even into Object C ad infinitum, via constructor. I changed the way that object was handled by Objects B and C, making a full on copy instead of just assigning the input reference to a new-instance variable, and the problem was finally solved in spite of still having both sets of updates installed. I felt pretty darn dumb.

    I spent around 3 weeks investigating every possible cross thread access or timing dependant cause for the issue until I boiled it down to 2 simple lines of code, as I didn't want to raise a question for an issue that could have any possibility of being something that I was doing incorrectly.  I don't see how there can possibly be other factors at play in an application with 2 lines of code, but please enlighten me if you can spot anything?

    Please see the entire source below:

    using System;
    using System.Windows.Forms;
    namespace TextBoxBug
        public partial class TextBoxBugForm : Form
            public TextBoxBugForm()
            private void breakLogButton_Click(object sender, EventArgs e)
                logTextBox.Text = "a\r\n";
                logTextBox.Text = "a\r"; // Application will lock here for 30 to 60s and use ~ 1.2GB memory

    I also find it more than just a coincidence that one of the updates in the 1809 release was the support for Unix and Mac line feed methods in Notepad.

    terça-feira, 15 de janeiro de 2019 13:26
  • Just to chip in, I have come across a very similar issue appending text to a TextBox control. We were somehow quite frequenctly splitting text up so that the \r and the \n were separated, so appending a line with a trailing \r and then appending the next bit of text with a leading \n.

    After a while, we were seeing 5 second delays adding a line of text to the TextBox.

    Refactoring the code to not split the \r\n pair up immediately fixed the issue.

    quarta-feira, 13 de março de 2019 17:37
  • I also find it more than just a coincidence that one of the updates in the 1809 release was the support for Unix and Mac line feed methods in Notepad.

    Did you check whether setting the 2 registry keys to revert Notepad's EOL behaviour to a pre-1809 state fixes the issue?
    terça-feira, 18 de junho de 2019 01:47