0
votes

We're seeing this exception show up in our logs: "1 is not a supported code page". It occurs randomly on the site, and at random times, but is always in 1 of 2 places: either reading the byte stream for an uploaded file, or writing a byte stream to the response. The error is hard to reproduce, and the fix has been to recycle the IIS node which has the problem.

File upload & download works works nearly all the time, so the code does work. We're not doing anything untoward like spinning off a background thread to do this processing, but the various libraries we're using might be.

Some examples:

From C# framework code:

Message : Unable to translate bytes [C0] at index 0 from specified code page to Unicode. StackTrace : at System.Text.DecoderExceptionFallbackBuffer.Throw(Byte[] bytesUnknown, Int32 index) at System.Text.DecoderExceptionFallbackBuffer.Fallback(Byte[] bytesUnknown, Int32 index) at System.Text.DecoderFallbackBuffer.InternalFallback(Byte[] bytes, Byte* pBytes, Char*& chars) at System.Text.UTF8Encoding.GetChars(Byte* bytes, Int32 byteCount, Char* chars, Int32 charCount, DecoderNLS baseDecoder) at System.Text.UTF8Encoding.GetChars(Byte[] bytes, Int32 byteIndex, Int32 byteCount, Char[] chars, Int32 charIndex) at System.Xml.ValueHandle.TryReadChars(Char[] chars, Int32 offset, Int32 count, Int32& actual) at System.Xml.XmlBaseReader.ReadValueChunk(Char[] chars, Int32 offset, Int32 count) at System.Xml.XmlBinaryWriter.WriteTextNode(XmlDictionaryReader reader, Boolean attribute) at System.Xml.XmlDictionaryWriter.WriteNode(XmlDictionaryReader reader, Boolean defattr) at System.ServiceModel.Channels.ReceivedMessage.OnWriteBodyContents(XmlDictionaryWriter writer) at System.ServiceModel.Channels.Message.OnWriteMessage(XmlDictionaryWriter writer) at System.ServiceModel.Channels.Message.OnCreateBufferedCopy(Int32 maxBufferSize, XmlDictionaryReaderQuotas quotas) at System.ServiceModel.Channels.Message.CreateBufferedCopy(Int32 maxBufferSize) at Daptiv.Api.WcfRest.ServiceModel.Extensions.XmlPropertySorterMessageInspector.AfterReceiveRequest(Message& request, IClientChannel channel, InstanceContext instanceContext) in {source redacted} at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.AfterReceiveRequestCore(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage2(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage11(MessageRpc& rpc) at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet) Source : mscorlib TargetSite : Void Throw(Byte[], Int32) HelpLink : {NULL} Index : 0 ParamName : {NULL} HResult : -2147024809 BytesUnknown : [Byte[]]: hashcode { 3297007 } { 192 } Data : [ListDictionaryInternal]: hashcode { 44361946 }{} InnerException : {NULL} }

From Aspose.Tasks:

Message : 1 is not a supported code page. Parameter name: codepage StackTrace : at System.Text.Encoding.GetEncoding(Int32 codepage) at ?.?.?() at ?.?..ctor(Stream stream) at ?.?.?(Stream ?) at ?.B.?() at Aspose.Cells.Workbook.?(Stream ?, LoadOptions ?) at Aspose.Cells.Workbook.?(String ?, LoadOptions ?) at

1
I'm guessing you are getting a certain file (maybe malformed) uploaded to your site. Do you have access to the file that was uploaded and caused this error? It would allow you to run it through again and find out exactly what is broken. - Ron Beyer
Thanks - we don't have access to the content being uploaded. See my answer below. - kirasglimmer
The stack trace shows a call to non-framework code at Daptiv.Api.WcfRest.ServiceModel.Extensions.XmlPropertySorterMessageInspector.AfterReceiveRequest. If this is your code, please update your question to show us what's happening in that method. Without seeing the code that is throwing the error, it's unlikely anyone will be able to help you. - Matt Johnson-Pint
Thanks Matt - no more help needed. I've marked the question answered. - kirasglimmer

1 Answers

0
votes

Thanks for taking the time to check this out. We continued to dig, and found a strong correlation between pages that were erroring out, and pages that used the Aspose.Cells assembly. We believe that upgrading this assembly will resolve the problem, since the one we are using is quite old.

So, for anybody looking at this issue in the future: check and make sure all your 3rd party assemblies are reasonably up to date. Anything older than a couple years should be considered suspect until proven otherwise.