none
System.NotSupportException: The URI Prefix is Not Recognized When Creating XPS Document RRS feed

  • Question

  • We have an application that implements a plug-in style architecture , using classes that implement MarhsalByRefObject,etc   In some instances, an attempt to call a method from one AppDoman to another that creates an XPS document will throw the following exception:

    UnhandledException event raised in MapInfoPro.exe: System.NotSupportedException: The URI prefix is not recognized.
       at System.Net.WebRequest.Create(Uri requestUri, Boolean useUriBase)
       at MS.Internal.WpfWebRequestHelper.CreateRequest(Uri uri)
       at System.IO.Packaging.PackWebRequest.GetRequest(Boolean allowPseudoRequest)
       at System.IO.Packaging.PackWebRequest.GetResponse()
       at MS.Internal.WpfWebRequestHelper.GetResponseStream(WebRequest request, ContentType& contentType)
       at System.Windows.Documents.PageContent._LoadPageImpl(Uri baseUri, Uri uriToLoad, FixedPage& fixedPage, Stream& pageStream)
       at System.Windows.Documents.PageContentAsyncResult.Dispatch(Object arg)
       at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
       at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
       at System.Windows.Threading.DispatcherOperation.InvokeImpl()
       at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Windows.Threading.DispatcherOperation.Invoke()
       at System.Windows.Threading.Dispatcher.ProcessQueue()
       at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
       at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
       at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
       at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
       at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
       at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
       at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
       at Microsoft.Win32.SafeNativeMethods.MessageBoxSystem(IntPtr hWnd, String text, String caption, Int32 type)
       at Microsoft.Win32.SafeNativeMethods.MessageBox(IntPtr hWnd, String text, String caption, Int32 type)
       at System.Diagnostics.AssertWrapper.ShowMessageBoxAssert(String stackTrace, String message, String detailMessage)
       at System.Diagnostics.DefaultTraceListener.Fail(String message, String detailMessage)
       at System.Diagnostics.TraceInternal.Fail(String message)
       at MapInfoPro.App.StartApplication(String[] args) in c:\workdata\MiProTeamline\MiPro_Trunk_New12\Assems\MapInfoPro\App.xaml.cs:line 138
       at MapInfoPro.MainClass.Main(String[] args) in c:\workdata\MiProTeamline\MiPro_Trunk_New12\Assems\MapInfoPro\App.xaml.cs:line 34

    The perplexing part is, the method the problem seems to originate from is simple:

    internal static IDocumentPaginatorSource GetInactiveContent(MemoryStream memStream, string memoryUri)
    {

    FixedDocumentSequence fixedDocSeq = null;

    var packageUri = new Uri(memoryUri);

    var package = Package.Open(memStream);

    PackageStore.AddPackage(packageUri, package);
    XpsDocument newDoc = null;

    newDoc = new XpsDocument(package, CompressionOption.Fast, memoryUri);

    fixedDocSeq = newDoc.GetFixedDocumentSequence();
    DocumentReference docReference = fixedDocSeq.References.First();
    FixedDocument doc = docReference.GetDocument(false);
    var fixedPage = doc.Pages[0].GetPageRoot(true);
    fixedPage.Background = Brushes.Transparent;


    return fixedDocSeq;
    }

    And it looks like the call to 'new XpsDocument' is what's causing it.   I say 'looks like' because removing that call eliminates the exception, but then we don't get the XpsDocument either.  Attempting to try/catch the exception here doesn't work,as it seems to bubble up through .NET and crash our application.

    This appears to be some sort of timing issue, as it only happens under certain circumstances, mostly involving cross domain content from the application be closed/opened rapidly.

    The URI's we are using are defined as:

    _FrameControlUri = string.Format("memorystream://printstream{0}", Guid.NewGuid().ToString("N"));

    In an attempt to keep them always unique, so it doesn't seem to be an issue with the URI itself, I'm suspicious that perhaps a package is somehow getting removed from the PackageStore and then the internal code .NET code to create the XPSDocument throws an exception.

    The application is very complex, and providing a small sample to reproduce the problem won't be possible.  If you could help me understand that exception message , and possibly point me in the right direction to working around or preventing the problem it would be greatly appreciated.

    Thanks,

    Chris


    Monday, October 26, 2015 9:20 PM

All replies

  •  Hi Chris, 

    "The URI prefix is not recognized." this indicates the uri is not correct. I suggest you set a breakpoint and debug step by step to check the URI.

      var packageUri = new Uri(memoryUri);
                MessageBox.Show(packageUri.AbsoluteUri);

    Then you'll see what's the uri you get, and determine if it's correct.

    Best regards,

    Kristin


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, October 27, 2015 5:55 AM
  • Hi Kristin,

    Thanks for the reply.  Yeah, I've looked at the URI many times and there's no reason to think that it isn't correct.  Do you know of a way to validate or check it, before I use it to try and create the XPS document?

    The URI's we're using typically look like:

    memorystream://printstream130904410046385825/

    Thanks,

    Chris

    Tuesday, October 27, 2015 5:41 PM
  • The error indicates "memorystream" is not one of the WebRequestModules defined in web.config/app.config/machine.config .

    If you think you should have registered that module in your project, please check again.

    Wednesday, October 28, 2015 1:54 AM
    Answerer
  • Interesting.  If it weren't registered correctly I'd figure this error would happen all the time, rather than intermittently under certain circumstances.  Is there a way to force that registration in code?
    Wednesday, October 28, 2015 3:34 PM
  • Ok I seem to be getting somewhere.  I'm attempting to register the 'memorystream' prefix in code before I make the call to create the XPS document.  Like this:

    var memURi = new MemoryStreamUri();

    WebRequest.RegisterPrefix("memorystream", memURi);

    implementing the following custom classes:

    public class MemoryStreamUri : IWebRequestCreate
    {

    public WebRequest Create(Uri uri)
    {
    return new MemoryStreamRequest(uri);
    }
    }

    public class MemoryStreamRequest : WebRequest
    {
    private Uri _uri;

    public MemoryStreamRequest(Uri uri)
    {
    _uri = uri;
    }

    public override Uri RequestUri
    {
    get { return _uri; }
    }


    }

    An error still gets thrown at the same time and place in application execution, but this time it's:

    UnhandledException event raised in MapInfoPro.exe: System.NotImplementedException: This property is not implemented by this class.
       at System.Net.WebRequest.get_Timeout()
       at System.IO.Packaging.PackWebResponse..ctor(Uri uri, Uri innerUri, Uri partName, WebRequest innerRequest)
       at System.IO.Packaging.PackWebRequest.GetResponse()
       at MS.Internal.WpfWebRequestHelper.GetResponseStream(WebRequest request, ContentType& contentType)
       at System.Windows.Documents.PageContent._LoadPageImpl(Uri baseUri, Uri uriToLoad, FixedPage& fixedPage, Stream& pageStream)
       at System.Windows.Documents.PageContentAsyncResult.Dispatch(Object arg)
       at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
       at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
       at System.Windows.Threading.DispatcherOperation.InvokeImpl()
       at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Windows.Threading.DispatcherOperation.Invoke()
       at System.Windows.Threading.Dispatcher.ProcessQueue()
       at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
       at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
       at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
       at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
       at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
       at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
       at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
       at Microsoft.Win32.SafeNativeMethods.MessageBoxSystem(IntPtr hWnd, String text, String caption, Int32 type)
       at Microsoft.Win32.SafeNativeMethods.MessageBox(IntPtr hWnd, String text, String caption, Int32 type)
       at System.Diagnostics.AssertWrapper.ShowMessageBoxAssert(String stackTrace, String message, String detailMessage)
       at System.Diagnostics.DefaultTraceListener.Fail(String message, String detailMessage)
       at System.Diagnostics.TraceInternal.Fail(String message)
       at MapInfoPro.App.StartApplication(String[] args) in c:\workdata\MiProTeamline\MiPro_Trunk_New12\Assems\MapInfoPro\App.xaml.cs:line 133
       at MapInfoPro.MainClass.Main(String[] args) in c:\workdata\MiProTeamline\MiPro_Trunk_New12\Assems\MapInfoPro\App.xaml.cs:line 32

    My questions for you are:

    1.)  Why is the 'memorystream' prefix working fine in most cases, and intermittently the prefix is 'not supported'?

    2.)  What is the correct way to 'register' the 'memorystream' URI prefix in our application? The MSDN documentation here is very sparse, and there isn't a lot of help on the web.

    Thanks,

    Chris

    Wednesday, October 28, 2015 6:53 PM
  • From the error message, your MomoryStreamRequest forgot to override Timeout property.

    1) I don't know, I just view the source code of WebRequest.Create() to trace back what could be missing. The documentation did mentioned the only guaranteed URI prefix handlers are "http", "https" and "file".

    2) You're doing it the correct way, just that you should override the abstract (i.e. virtual) members in the WebRequest class to provide implementation for it to work.

    You can see that in the default Timeout implementation provided by the class, calling getter just throws PropertyNotImplementedException.

    Since you're using memorystream, seems let it always returns Timeout.Infinate to tell it to shutup and go back to work is enough.

    If you're using the webrequest directly, you can bypass writing code for those members when you avoid using it entirely. Since from the stacktrace it's other component using it, you'll have to do it step-by-step to implement each and every members it'll call.

    You can always check whether you need to implement it or accept the default implementation by checking the referencesource site that I linked to. A good start is to check the PackWebResponse code and see how it uses the WebRequest.



    Thursday, October 29, 2015 1:55 AM
    Answerer
  • Hi, thanks for your response.  

    Based on your reply and further research into WebRequest handlers, I went and changed our 'memorystream' prefix to 'file', as it really doesn't matter for our purposes - we just need a valid URI to our content.

    Now, I am getting this exception:

    UnhandledException event raised in MapInfoPro.exe: System.Net.WebException: The network path was not found.
     ---> System.Net.WebException: The network path was not found.
     ---> System.IO.IOException: The network path was not found.

       at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
       at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
       at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
       at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean useAsync)
       at System.Net.FileWebStream..ctor(FileWebRequest request, String path, FileMode mode, FileAccess access, FileShare sharing, Int32 length, Boolean async)
       at System.Net.FileWebResponse..ctor(FileWebRequest request, Uri uri, FileAccess access, Boolean asyncHint)
       --- End of inner exception stack trace ---
       at System.Net.FileWebResponse..ctor(FileWebRequest request, Uri uri, FileAccess access, Boolean asyncHint)
       at System.Net.FileWebRequest.GetResponseCallback(Object state)
       --- End of inner exception stack trace ---
       at System.IO.Packaging.PackWebResponse.WaitForResponse()
       at System.IO.Packaging.PackWebResponse.get_ContentType()
       at MS.Internal.WpfWebRequestHelper.GetContentType(WebResponse response)
       at MS.Internal.WpfWebRequestHelper.GetResponseStream(WebRequest request, ContentType& contentType)
       at System.Windows.Documents.PageContent._LoadPageImpl(Uri baseUri, Uri uriToLoad, FixedPage& fixedPage, Stream& pageStream)
       at System.Windows.Documents.PageContentAsyncResult.Dispatch(Object arg)
       at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
       at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
       at System.Windows.Threading.DispatcherOperation.InvokeImpl()
       at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Windows.Threading.DispatcherOperation.Invoke()
       at System.Windows.Threading.Dispatcher.ProcessQueue()
       at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
       at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
       at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
       at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
       at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
       at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
       at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
       at Microsoft.Win32.SafeNativeMethods.MessageBoxSystem(IntPtr hWnd, String text, String caption, Int32 type)
       at Microsoft.Win32.SafeNativeMethods.MessageBox(IntPtr hWnd, String text, String caption, Int32 type)
       at System.Diagnostics.AssertWrapper.ShowMessageBoxAssert(String stackTrace, String message, String detailMessage)
       at System.Diagnostics.DefaultTraceListener.Fail(String message, String detailMessage)
       at System.Diagnostics.TraceInternal.Fail(String message)
       at MapInfoPro.App.StartApplication(String[] args) in c:\workdata\MiProTeamline\MiPro_Trunk_New12\Assems\MapInfoPro\App.xaml.cs:line 133
       at MapInfoPro.MainClass.Main(String[] args) in c:\workdata\MiProTeamline\MiPro_Trunk_New12\Assems\MapInfoPro\App.xaml.cs:line 32

    Again, the problem is intermittent.  Our configuration works, most of the time.  

    What could be causing this error?  Does it look like a package is missing from the PackageStore, possibly?

    Thanks,

    C


    • Edited by Awake77 Thursday, October 29, 2015 5:53 PM
    Thursday, October 29, 2015 5:49 PM
  • The WebRequest will be used to retrieve the content of file to render. If that is not a valid path, of course it'll throw exception saying "The network path was not found".

    Implement a correct URI scheme handler is the right way to go.

    Friday, October 30, 2015 1:16 AM
    Answerer
  • Yes.  I've implemented a URI scheme that has got around the 'invalid prefix' error.  Now, I am getting the 'net work path was not found' exception at the same point in program execution, and this appears to be coming out of System.Net.FileWebResponse:

    System.dll!System.Net.FileWebResponse.FileWebResponse(System.Net.FileWebRequest request, System.Uri uri, System.IO.FileAccess access, bool asyncHint) + 0x283 bytes
      System.dll!System.Net.FileWebRequest.GetResponseCallback(object state) + 0x1e9 bytes
      mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x285 bytes
      mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x9 bytes
      mscorlib.dll!System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem() + 0x6f bytes
      mscorlib.dll!System.Threading.ThreadPoolWorkQueue.Dispatch() + 0x1ea bytes
      [Native to Managed Transition]
      kernel32.dll!BaseThreadInitThunk()  + 0x22 bytes
      ntdll.dll!RtlUserThreadStart()  + 0x34 bytes

    I appears that this is being thrown by our WPF DocumentViewer once it relieves a PropertyChanged event that its bound to to update it's contained Document.  It looks as if it's the actual display of the content that's triggering the exception, and I can't catch it as it's happening in the WPF layer.  VisualStudio is telling me the exception is coming out of PresentationCore.dll.

    The URI appears valid, and checking the PackageStore for that URI right before firing the PropertyChanged event returns a valid result. 

    Is there any way to catch an exception like this?  Our application is entering some sort of state that's causing this issue, and I'm trying to track that down.   I've ensured that my URI's are in the correct format and are valid up until the point of the display, but the exception is still getting thrown when the DocumentViewer receives that event.

    If there was a way to catch this exception it would really help, any ideas?


    Monday, November 2, 2015 6:36 PM
  • Try implement a Unhandled Exception Handler and throw the exception if it is not a WebException then. (Don't look for "The network path was not found." as the wordings will change if the user runs it with different language version of .NET runtime.)
    Tuesday, November 3, 2015 1:22 AM
    Answerer
  • it does look like it is actually a WebException that is bubbling up and crashing our application.  But this exception is being thrown when the DocumentViewer goes to display it's content.

    For instance, a call to DocumentViewer.UpdateLayout() will end up throwing the exception.  But if I wrap this call with a try/catch block, i still can't catch it.

    I have tried implementing the DispatcherUnhandledException, but that doesn't appear to help.

    Checking for the System.Net.WebException in our App.xaml.cs code, and trying to get around it ends up throwing this error:

    An exception of type 'System.Net.WebException' occurred in PresentationCore.dll and wasn't handled before a managed/native boundary

    Additional information: The network path was not found.

    Our application does use both .NET and C++ (as well as managed C++).  Apparently the .NET exception needs to be addressed before it can continue, leading to the crash.

    Any other ideas on how to  catch this?  Is there a way I can check of the DocuementViewer or its Document are valid before allowing it to render?  

    Wednesday, November 4, 2015 6:03 PM
  • Hi,

    I got exactly the same issue. And I did a lot of investigation of it, including going through the .net sources. I ended up with no solution. Neither checking the correctes in advance nor catching and handling the exception thrown is possible. My application is heavily using XpsDocuments together with in memory resources. And from time to time it crashes.

    So did you find any solution?

    Thanks,
    Headi

    Wednesday, August 24, 2016 9:20 AM