Try our conversational search powered by Generative AI!
AI OnAI Off
"Invalid URI" exception thrown in View Mode, but not Edit Mode
Hi Dean!
When you click on "go to view mode" you actually load a specific "go to view mode"-page that's takes care of resolving the url for the page. I can't see if it's this page or the actual template that throws the exception. If it's the viewmodetransferpage I guess that it's a bug in EPiServer UIs. If it's the template, are you getting the same error when browsing to the page from the site?
Apr 14, 2011 7:11
It's getting past the "go to view mode" page. The URL in the browser bar is the actual URL of the page. If I just type that URL into a browser, I get the error too, so the error is coming from the page itself.
Apr 14, 2011 15:23
Since I love a debugging challenge, I'll chime in here!
I believe that the answer to your question is in the value of the parameter "uri" to System.Uri.CreateThis. Let me explain how I would troubleshoot this.
I would use WinDbg to attach to the web process, set a breakpoint at the UriFormatException constructor, and examine the parameters to the methods in the call stack. In more detail, this is how you do it.
- Download WinDbg, which is part of the Debugging Tools for Windows. It is installed with Windows SDK at http://msdn.microsoft.com/en-us/windows/hardware/gg463009
- Launch WinDbg (there are two versions, Windows SDK installer installs the one for your platform but you should use the one that have the same 32/64-bit as the target process)
- Press F6 to attach to a running web server process. Choose the one where you can get the UriFormatException. You can use the command "%windir%\system32\inetsrv\appcmd list wp" to find the PID of all running worker processes, if you run IIS7.
- Enter the WinDbg command ".loadby sos mscorwks" to load the managed debugging extension. If you run .NET 4, replace mscorwks with clr.
- Enter the WinDbg command "!name2ee System.dll System.UriFormatException" and find the address of the MethodTable. Let's say it is 5570470c.
- Enter the WinDbg command "!dumpmt -md 5570470c" (use the MethodTable address from point 5). This will list the methods of the class. Pick the MethodDesc address of the constructor that we should use as breakpoint. Select one with a string input parameter, as the exception message isn't generic but probably provided by the CreateThis method. Let's say it is 55460b0c.
- Enter the WinDbg command "!bpmd -md 55460b0c". Now you have a break point set at the address of the method that you chose in step 6. You may repeat this step to set multiple breakpoints.
- Enter the WinDbg command "g". This will let the process run until it hits a breakpoint
- Provoke the exception on the site. Hopefully, WinDbg will react and halt the process before the exception is shown in the browser. We now have the opportunity to examine the call stack and its parameters.
- Enter the WinDbg command "!clrstack -a" to find a quite verbose version of the current call stack. As a part of each method invocation, WinDbg will show the address to each parameter that is still available in the stack. (In release mode, some parameters gets optimized away)
- Use the WinDbg command "!do <address>" to examine (dump) objects. Find the parameter presenting the value of the Uri, and dump it. This will likely show the source of your problem.
- If you determine that this isn't the particular instance of UriFormatException that you were looking for, continue executing the code by typing "g" into the command line.
- You may also use "!dso" to Dump all Stack Objects. This might give you an insight into the execution context of the stack trace.
Use "!help" for SOS extension command summary.
HTH and happy hacking,
Kristoffer
Apr 17, 2011 1:46
I found the problem -- I was rewriting a malformed URL. I was putting something on the end of it, and it was all screwed up.
In Edit Mode this went AFTER the querystring that Edit Mode adds, so it worked. In View Mode, there was no querystring, so the thing I was putting on the end was counted as part of the domain. Like so:
IN EDIT MODE:
http://mydomain.com/thispage?id=123[my screwed up stuff here]
IN VIEW MODE:
http://mydomain.com[my screwed up stuff here]
The second version resulted in a URL that wouldn't parse.
Smooth, I know.
Edited,
Apr 26, 2011 23:05
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
I have a truly bizarre problem. I have a page template with a custom control on it. When it renders in Edit Mode, all is well. However, when it renders in View Mode (so, when I click the "eyeball" icon in the top left of Edit Mode), it throws this error:
Now, I'm deeply confused about this, because I can't see how the server knows that the page is being request from Edit or View Mode, so how can it consistently throw this error in one mode or the other?
The error seems to be coming out of EPiServer's HTML rewriting system. It looks like it's not happy with a link on the page, but this link would be there in Edit Mode too, so I can't understand why it overlooks a bad link then, but throws an error in View Mode.
My question, then is two-fold:
- Has anyone seen this error? What type of link is the rewriter concerned about?
- Why would this error throw in Edit Mode, but not View Mode?
[UriFormatException: Invalid URI: The hostname could not be parsed.] at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind) at EPiServer.UrlBuilder..ctor(UrlBuilder url) at EPiServer.Web.FriendlyUrlRewriteProvider.ConvertToInternal(UrlBuilder url, Object& internalObject) at EPiServer.Web.UrlRewriteModule.HttpUrlRewriteToInternal(UrlBuilder url) at EPiServer.Web.UrlRewriteModuleBase.BeginRequestEventHandler(Object sender, EventArgs e)