none
NullReferenceException at System.Text.UTF8Encoding.GetMaxByteCount(Int32) RRS feed

  • Question

  • We receive the exception below in one of our installations. The same code works perfectly in other servers, but on one server, we receive this exception.

    It is a Windows Server 2012 R2 Standard, 64-bit Operating System.

    The last .Net Framework Version installed on that machine is 4.8. The machine is restarted regularly, but the error persists.

    I wonder if anyone else received this NullReferenceException at System.Text.UTF8Encoding.GetMaxByteCount(Int32).

    If yes, how did you solve it? If not, any tips to prevent this exception?

    System.NullReferenceException: Object reference not set to an instance of an object.
       at System.Text.UTF8Encoding.GetMaxByteCount(Int32 charCount)        
       at System.IO.StreamWriter.Init(Stream streamArg, Encoding encodingArg, Int32 bufferSize, Boolean shouldLeaveOpen)        
       at System.IO.StreamWriter..ctor(Stream stream, Encoding encoding, Int32 bufferSize, Boolean leaveOpen)        
       at System.IO.StreamWriter..ctor(Stream stream, Encoding encoding)        
       at System.Xml.XmlTextWriter..ctor(Stream w, Encoding encoding)        
       at MS.Internal.IO.Packaging.InternalRelationshipCollection.WriteRelationshipPart(PackagePart part)        
       at MS.Internal.IO.Packaging.InternalRelationshipCollection.Flush()        
       at System.IO.Packaging.Package.System.IDisposable.Dispose()        
       at Infragistics.Documents.Core.Packaging.PackageWrapper.Dispose()        
       at Infragistics.Documents.OfficeOpenXml.Core.OfficeDocumentManager.Dispose(Boolean disposing)        
       at Infragistics.Documents.OfficeOpenXml.Core.OfficeDocumentManager.System.IDisposable.Dispose()        
       at Infragistics.Documents.Excel.Serialization.WorkbookSaveManagerExcel2007.Dispose(Boolean disposing)        
       at Infragistics.Documents.Excel.Serialization.WorkbookSerializationManager.System.IDisposable.Dispose()        
       at Infragistics.Documents.Core.Async.UsingHelper`1.<Execute>b__3_1()        
       at Infragistics.Documents.Core.WorkItem.WorkItemSync.ExecuteCore(WorkItemScheduler scheduler)        
       at Infragistics.Documents.Core.WorkItem.Execute(WorkItemScheduler scheduler)        
    --- End of stack trace from previous location where exception was thrown ---        
       at TryThrowExceptionDispatchInfo(Object )        
       at Infragistics.Documents.Core.WorkItem.ExceptionInfo.Rethrow()        
       at Infragistics.Documents.Core.WorkItem.RunNextWorkItem(WorkItemScheduler scheduler)        
       at Infragistics.Documents.Core.WorkItem.Execute(WorkItemScheduler scheduler)        
       at Infragistics.Documents.Core.WorkItemScheduler.SynchronousImpl.Execute(WorkItem workItem)        
       at Infragistics.Documents.Excel.Workbook.Save(String fileName, WorkbookSaveOptions saveOptions)

    Thursday, November 14, 2019 11:50 AM

All replies

  • Hello,

    A guess, if both servers have the same .NET Framework installed and this only happens on one server perhaps there is a permission issue? Also, is the source for this method against the exact same source that is working?

    You might consider showing your code, just enough for those who want to assist to have a starting point.


    Please remember to mark the replies as answers if they help and unmarked 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.

    NuGet BaseConnectionLibrary for database connections.

    StackOverFlow
    profile for Karen Payne on Stack Exchange

    Thursday, November 14, 2019 1:35 PM
    Moderator
  • Thank you for your response, Karen.

    Can you elaborate on what you mean with "permission issue?" I think that is more the direction that we have to look at.

    "is the source for this method against the exact same source that is working?" Yes, they are the exact same source code. One server is our test server. The other one is in the premises of the customer.

    The problem is that the entire stack trace that you see there is third party code. So, I don't have any access to the Infragistics code.

    I asked them in their forums, but they cannot reproduce it either.
    Thursday, November 14, 2019 1:50 PM
  • Hi gpsdev,

    Thank you for posting here.

    Could you please provide some code that we can run? We can't reproduce your error with only the error message.

    Looking forward to your reply.

    Best Regards,

    Timon


    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 MSDNFSF@microsoft.com.

    Friday, November 15, 2019 8:18 AM
  • This error is being caused by a third party product. Specifically your use of Infragistics to work with Office documents. You should post in their forums. They could have a bug.

    Michael Taylor http://www.michaeltaylorp3.net

    Friday, November 15, 2019 2:53 PM
    Moderator
  • Thank you for your response, Karen.

    Can you elaborate on what you mean with "permission issue?" I think that is more the direction that we have to look at.

    "is the source for this method against the exact same source that is working?" Yes, they are the exact same source code. One server is our test server. The other one is in the premises of the customer.

    The problem is that the entire stack trace that you see there is third party code. So, I don't have any access to the Infragistics code.

    I asked them in their forums, but they cannot reproduce it either.

    By permission, perhaps the person operating the program does not have permissions from Active Directory. 

    My gut says this is not a reproducible issues as it's not code related but the environment being executed from. So it's not a code issue.


    Please remember to mark the replies as answers if they help and unmarked 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.

    NuGet BaseConnectionLibrary for database connections.

    StackOverFlow
    profile for Karen Payne on Stack Exchange

    Friday, November 15, 2019 3:08 PM
    Moderator
  • I asked them in their forums, but they cannot reproduce it either.
    Friday, November 15, 2019 3:23 PM
  • Thank you for the tip, Karen. The code runs as a service. I should have mentioned that in the original post.

    In the mean time, my colleague could isolate the issue.

    Now, instead of using "Encoding.UTF8", we use a local variable initialized with "new UTF8Encoding(true, true)".

    If that local variable gets corrupted, the static Encoding.UTF8 (and with that the rest of the system) stays intact.

    If I find something more, I'll keep this thread up to date.

    Friday, November 15, 2019 3:31 PM
  • You might look at user settings for their computer for locale. Also if possible log them into a working machine, does the problem persist?

    Please remember to mark the replies as answers if they help and unmarked 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.

    NuGet BaseConnectionLibrary for database connections.

    StackOverFlow
    profile for Karen Payne on Stack Exchange

    Friday, November 15, 2019 3:52 PM
    Moderator