[further infos missing] MP2.2 client crashes on open (after upgrade) (2 Viewers)

[tlhackque]

The 2.2 version has the new HttpListener implementation for UPnP and ResourceServer. All components share the same IP port 55555 (also client and server process on same machine).
If this port is occupied already by another process, it will cause conflicts.
Also the installer adds an access rule to the HttpListener. If it was not successful, the port can't be opened.
So for troubleshooting you might first check if port 55555 is free and also accessible through firewall.

To gather some more data, I tried updating 2.1.3 to 2.2 again.

First, I used netstat -b -q (with 2.1.3 running). Port 55555 is not listed in use. I checked the firewall; it is open to all connections from the local subnet (IPv4 and IPv6).

Next, I updated to 2.2.

If you ever try again, try to run: "netsh show urlacl" from a command line and find the reservation for MediaPortal.

I assume you meant "netsh http show urlacl", which results in:

Reserved URL : http://+:55555/MediaPortal/
User: \Everyone
Listen: Yes
Delegate: No
SDDL: DA;;GX;;;WD)​

I again ran netstat -b -q (now with 2.2 installed).
55555 seems to be available for (and used by) MP2. Here are the netstat results (I include only the lines with 55555 & MP2-*)

TCP 0.0.0.0:55555 Scream:0 LISTENING
Can not obtain ownership information
TCP 127.0.0.1:51819 Scream:55555 TIME_WAIT
TCP 127.0.0.1:51820 Scream:55555 TIME_WAIT
TCP 127.0.0.1:51821 Scream:55555 TIME_WAIT
TCP 127.0.0.1:51822 Scream:55555 TIME_WAIT
TCP 127.0.0.1:51823 Scream:55555 TIME_WAIT
TCP 127.0.0.1:51824 Scream:55555 TIME_WAIT
TCP [::]:55555 Scream:0 LISTENING
Can not obtain ownership information

TCP 0.0.0.0:31456 Scream:0 LISTENING
[MP2-Server.exe]
TCP 0.0.0.0:51734 Scream:0 LISTENING
[MP2-Server.exe]
TCP 192.168.56.1:31456 Scream:52087 ESTABLISHED
[MP2-Server.exe]
TCP 192.168.56.1:31456 Scream:52088 ESTABLISHED
[MP2-Server.exe]
TCP 192.168.56.1:52087 Scream:31456 ESTABLISHED
[MP2-Server.exe]
TCP 192.168.56.1:52088 Scream:31456 ESTABLISHED
[MP2-Server.exe]
TCP 192.168.148.110:554 Scream:0 LISTENING
[MP2-Server.exe]
UDP 127.0.0.1:1900 *:*
[MP2-Server.exe]
UDP 127.0.0.1:1900 *:*
[MP2-Server.exe]
UDP 127.0.0.1:1900 *:*
[MP2-Server.exe]
UDP 127.0.0.1:1900 *:*
[MP2-ServiceMonitor.exe]
UDP 127.0.0.1:1900 *:*
[MP2-Server.exe]
UDP 127.0.0.1:1900 *:*
[MP2-Server.exe]
UDP 127.0.0.1:7900 *:*
[MP2-ServiceMonitor.exe]
UDP 127.0.0.1:55907 *:*
[MP2-ServiceMonitor.exe]
UDP 127.0.0.1:60948 *:*
[MP2-Server.exe]
UDP 127.0.0.1:61045 *:*
[MP2-Server.exe]
UDP 127.0.0.1:62638 *:*
[MP2-Server.exe]
UDP 192.168.56.1:1900 *:*
[MP2-Server.exe]
UDP 192.168.56.1:1900 *:*
[MP2-Server.exe]
UDP 192.168.56.1:1900 *:*
[MP2-Server.exe]
UDP 192.168.56.1:1900 *:*
[MP2-Server.exe]
UDP 192.168.56.1:1900 *:*
[MP2-Server.exe]
UDP 192.168.56.1:1900 *:*
[MP2-ServiceMonitor.exe]
UDP 192.168.56.1:55914 *:*
[MP2-ServiceMonitor.exe]
UDP 192.168.56.1:60955 *:*
[MP2-Server.exe]
UDP 192.168.56.1:61052 *:*
[MP2-Server.exe]
UDP 192.168.56.1:62645 *:*
[MP2-Server.exe]
UDP 192.168.148.110:1900 *:*
[MP2-Server.exe]
UDP 192.168.148.110:1900 *:*
[MP2-Server.exe]
UDP 192.168.148.110:1900 *:*
[MP2-Server.exe]
UDP 192.168.148.110:1900 *:*
[MP2-Server.exe]
UDP 192.168.148.110:1900 *:*
[MP2-ServiceMonitor.exe]
UDP 192.168.148.110:1900 *:*
[MP2-Server.exe]
UDP 192.168.148.110:55915 *:*
[MP2-ServiceMonitor.exe]
UDP 192.168.148.110:60956 *:*
[MP2-Server.exe]
UDP 192.168.148.110:61053 *:*
[MP2-Server.exe]
UDP 192.168.148.110:62646 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:941::110]:1900 *:*
[MP2-ServiceMonitor.exe]
UDP [2001:470:8f95:941::110]:1900 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:941::110]:1900 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:941::110]:1900 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:941::110]:1900 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:941::110]:1900 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:941::110]:55913 *:*
[MP2-ServiceMonitor.exe]
UDP [2001:470:8f95:941::110]:60954 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:941::110]:61051 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:941::110]:62644 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:941:28da:f5ec:94ec:e30d]:1900 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:941:28da:f5ec:94ec:e30d]:1900 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:941:28da:f5ec:94ec:e30d]:1900 *:*
[MP2-ServiceMonitor.exe]
UDP [2001:470:8f95:941:28da:f5ec:94ec:e30d]:1900 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:941:28da:f5ec:94ec:e30d]:1900 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:941:28da:f5ec:94ec:e30d]:1900 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:941:28da:f5ec:94ec:e30d]:55912 *:*
[MP2-ServiceMonitor.exe]
UDP [2001:470:8f95:941:28da:f5ec:94ec:e30d]:60953 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:941:28da:f5ec:94ec:e30d]:61050 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:941:28da:f5ec:94ec:e30d]:62643 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:942:28da:f5ec:94ec:e30d]:1900 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:942:28da:f5ec:94ec:e30d]:1900 *:*
[MP2-ServiceMonitor.exe]
UDP [2001:470:8f95:942:28da:f5ec:94ec:e30d]:1900 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:942:28da:f5ec:94ec:e30d]:1900 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:942:28da:f5ec:94ec:e30d]:1900 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:942:28da:f5ec:94ec:e30d]:1900 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:942:28da:f5ec:94ec:e30d]:55911 *:*
[MP2-ServiceMonitor.exe]
UDP [2001:470:8f95:942:28da:f5ec:94ec:e30d]:60952 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:942:28da:f5ec:94ec:e30d]:61049 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:942:28da:f5ec:94ec:e30d]:62642 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:943:28da:f5ec:94ec:e30d]:1900 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:943:28da:f5ec:94ec:e30d]:1900 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:943:28da:f5ec:94ec:e30d]:1900 *:*
[MP2-ServiceMonitor.exe]
UDP [2001:470:8f95:943:28da:f5ec:94ec:e30d]:1900 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:943:28da:f5ec:94ec:e30d]:1900 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:943:28da:f5ec:94ec:e30d]:1900 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:943:28da:f5ec:94ec:e30d]:55910 *:*
[MP2-ServiceMonitor.exe]
UDP [2001:470:8f95:943:28da:f5ec:94ec:e30d]:60951 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:943:28da:f5ec:94ec:e30d]:61048 *:*
[MP2-Server.exe]
UDP [2001:470:8f95:943:28da:f5ec:94ec:e30d]:62641 *:*
[MP2-Server.exe]
UDP [fe80::13b:c45e:3493:cd76%18]:1900 *:*
[MP2-Server.exe]
UDP [fe80::13b:c45e:3493:cd76%18]:1900 *:*
[MP2-Server.exe]
UDP [fe80::13b:c45e:3493:cd76%18]:1900 *:*
[MP2-Server.exe]
UDP [fe80::13b:c45e:3493:cd76%18]:1900 *:*
[MP2-Server.exe]
UDP [fe80::13b:c45e:3493:cd76%18]:1900 *:*
[MP2-ServiceMonitor.exe]
UDP [fe80::13b:c45e:3493:cd76%18]:1900 *:*
[MP2-Server.exe]
UDP [fe80::13b:c45e:3493:cd76%18]:55908 *:*
[MP2-ServiceMonitor.exe]
UDP [fe80::13b:c45e:3493:cd76%18]:60949 *:*
[MP2-Server.exe]
UDP [fe80::13b:c45e:3493:cd76%18]:61046 *:*
[MP2-Server.exe]
UDP [fe80::13b:c45e:3493:cd76%18]:61952 *:*
SSDPSRV
[svchost.exe]
UDP [fe80::13b:c45e:3493:cd76%18]:62639 *:*
[MP2-Server.exe]
UDP [fe80::28da:f5ec:94ec:e30d%10]:1900 *:*
[MP2-Server.exe]
UDP [fe80::28da:f5ec:94ec:e30d%10]:1900 *:*
[MP2-Server.exe]
UDP [fe80::28da:f5ec:94ec:e30d%10]:1900 *:*
[MP2-Server.exe]
UDP [fe80::28da:f5ec:94ec:e30d%10]:1900 *:*
[MP2-Server.exe]
UDP [fe80::28da:f5ec:94ec:e30d%10]:1900 *:*
[MP2-Server.exe]
UDP [fe80::28da:f5ec:94ec:e30d%10]:1900 *:*
[MP2-ServiceMonitor.exe]
UDP [fe80::28da:f5ec:94ec:e30d%10]:55909 *:*
[MP2-ServiceMonitor.exe]
UDP [fe80::28da:f5ec:94ec:e30d%10]:60950 *:*
[MP2-Server.exe]
UDP [fe80::28da:f5ec:94ec:e30d%10]:61047 *:*
[MP2-Server.exe]
UDP [fe80::28da:f5ec:94ec:e30d%10]:62640 *:*
[MP2-Server.exe] ​

​

To completely rule out firewall issues, I disabled the firewall, restarted the MP2-Server service & verified that the client still does not start.

I captured the logs - but didn't attach them here since the logs from the previous attempt should be the same.

Crash.log still shows the same exception:

System.Net.HttpListenerException: Access is denied
at System.Net.HttpListener.AddAllPrefixes()
at System.Net.HttpListener.Start()
at Microsoft.Owin.Host.HttpListener.OwinHttpListener.Start(HttpListener listener, Func`2 appFunc, IList`1 addresses, IDictionary`2 capabilities, Func`2 loggerFactory)
at Microsoft.Owin.Host.HttpListener.OwinServerFactory.Create(Func`2 app, IDictionary`2 properties)
--- End of inner exception stack trace ---​

What is HttpListener.AddAllPrefixes() doing? I set a VS breakpoint on exception (in the client .exe) and extracted the following:

System.Net.HttpListenerException
HResult=0x80004005
Message=Access is denied
Source=System
StackTrace:
at System.Net.HttpListener.AddAllPrefixes() in f:\dd\NDP\fx\src\net\System\Net\HttpListener.cs:line 1133​

The call stack seems to indicate an issue starting the Resource Server. (It's not obvious to me why a client contains an HTTP server - but I don't claim to know anything about MP architecture.) The exception is from fairly deep in System.dll. I don't have sources, and visual studio doesn't seem to know where to find them.

> System.dll!System.Net.HttpListener.AddAllPrefixes() Line 1133 C#
System.dll!System.Net.HttpListener.Start() Line 862 C#
Microsoft.Owin.Host.HttpListener.dll!Microsoft.Owin.Host.HttpListener.OwinHttpListener.Start(System.Net.HttpListener listener, System.Func<System.Collections.Generic.IDictionary<string, object>, System.Threading.Tasks.Task> appFunc, System.Collections.Generic.IList<System.Collections.Generic.IDictionary<string, object>> addresses, System.Collections.Generic.IDictionary<string, object> capabilities, System.Func<string, System.Func<System.Diagnostics.TraceEventType, int, object, System.Exception, System.Func<object, System.Exception, string>, bool>> loggerFactory) Unknown
Microsoft.Owin.Host.HttpListener.dll!Microsoft.Owin.Host.HttpListener.OwinServerFactory.Create(System.Func<System.Collections.Generic.IDictionary<string, object>, System.Threading.Tasks.Task> app, System.Collections.Generic.IDictionary<string, object> properties) Unknown
[Native to Managed Transition]
[Managed to Native Transition]
Microsoft.Owin.Hosting.dll!Microsoft.Owin.Hosting.ServerFactory.ServerFactoryAdapter.Create(Owin.IAppBuilder builder) Unknown
Microsoft.Owin.Hosting.dll!Microsoft.Owin.Hosting.Engine.HostingEngine.StartServer(Microsoft.Owin.Hosting.Engine.StartContext context) Unknown
Microsoft.Owin.Hosting.dll!Microsoft.Owin.Hosting.Engine.HostingEngine.Start(Microsoft.Owin.Hosting.Engine.StartContext context) Unknown
Microsoft.Owin.Hosting.dll!Microsoft.Owin.Hosting.WebApp.StartImplementation(System.IServiceProvider services, Microsoft.Owin.Hosting.StartOptions options, System.Action<Owin.IAppBuilder> startup) Unknown
Microsoft.Owin.Hosting.dll!Microsoft.Owin.Hosting.WebApp.Start(Microsoft.Owin.Hosting.StartOptions options, System.Action<Owin.IAppBuilder> startup) Unknown
MediaPortal.Common.dll!MediaPortal.Common.Services.ResourceAccess.ResourceServer.CreateAndStartServer() Unknown
MediaPortal.Common.dll!MediaPortal.Common.Services.ResourceAccess.ResourceServer.ResourceServer() Unknown
MediaPortal.Common.dll!MediaPortal.Common.ApplicationCore.RegisterCoreServices() Unknown
MP2-Client.exe!MediaPortal.Client.ApplicationLauncher.Main(string[] args) Unknown​

​

I don't think I can do anything more to isolate this, so I'm dropping back to 2.1.3.

Perhaps you could enhance your logging to provide more information.

 

[henso]

I assume you meant "netsh http show urlacl"

Correct.
Do you have the file "MediaPortal.Common.Services.ResourceAccess.Settings.ServerSettings.xml" in your client config folder? If yes, could you post the content?

 

[tlhackque]

Correct.
Do you have the file "MediaPortal.Common.Services.ResourceAccess.Settings.ServerSettings.xml" in your client config folder? If yes, could you post the content?

Yes, Done. (This is with 2.1.3 running)

 

[henso]

Yes, Done.

Is the IP binding in it necessary? If not, could you remove it (delete the "IPAddressBindings" property) and try again when you find time?
If it doesn't help, you could also try changing the "UseIPv6" property to "false" to see if that helps.

 

[tlhackque]

Is the IP binding in it necessary? If not, could you remove it (delete the "IPAddressBindings" property) and try again when you find time?
If it doesn't help, you could also try changing the "UseIPv6" property to "false" to see if that helps.

The IP binding is because, as noted earlier, there is an interface with a subnet that is not routed off-host. Things could get very confusing if that were used by MP. Also, from time to time other IP addresses are added to the host, Services are run on these IP addresses with address+port pinholes in the firewall. For both those reasons, I bind to an always-present address that is routed. Also, I have been known to run a client on another host - in which case, only the routed IP address is useful.

I noticed that (shown above) the server is listening on 0.0.0.0::55555, not the specified address.

ProgramData\Team MediaPortal\MP2-Server\Config also contains a MediaPortal.Common.Services.ResourceAccess.Settings.ServerSettings.xml. This file does not specify an IP address; it specifies port '0'. Should it match the client? (I don't see an option for it in the server config utility - I have not manually edited any MP config files.)

Because switching versions takes about an hour, I would be more comfortable if we could determine exactly what is triggering the exception. Either with better logging, or a debug build that I extract meaningful data from at a breakpoint... If we knew what operation+resource is triggering the exception, it seems to me that this could be diagnosed more quickly.

The only other clue is that there are no config changes (other than anything Setup does) between MP2.1.3 (works) and 2.2 (doesn't).

 

[henso]

This file does not specify an IP address; it specifies port '0'

I think port 0 means auto which would mean port 55555. I don't know exactly what the requirements are between the server an the client config, but then you can probably not have the client and server running on the same PC because they will want to listen on the same port. @morpheus_xx care to comment?

If we knew what operation+resource is triggering the exception, it seems to me that this could be diagnosed more quickly

It seems the exception happens in Microsoft code, so I don't think it is possible to add more logging. @morpheus_xx any ideas?

The only other clue is that there are no config changes (other than anything Setup does) between MP2.1.3 (works) and 2.2 (doesn't).

The whole HTTP server is different. We changed from our own implemented HTTP server (it was having performance issues) to one implemented by Microsoft. They are internally completely different, so even if we set them up the same way they might still behave differently. Now we hopefully just need to determine what additional setup is necessary to make it work like expected.

 

[tlhackque]

you can probably not have the client and server running on the same PC because they will want to listen on the same port.

I'm not familiar with the .Net HTTP server. But I found some documentation that says that it allows you to share a port by routing requests based on the URI namespace. See this page.

It seems the exception happens in Microsoft code, so I don't think it is possible to add more logging.

It ought to be possible to log whatever arguments are passed to the Microsoft code. "Access Denied" should result from some operation on some resource. Knowing these would be helpful. If we knew exactly what is being passed to the Microsoft code, we should be able to figure this out.

Also, I forgot to say that I tried running the client as Administrator. It still generated the same exception. The exception might be because of conflicting registrations for the URI namespace.

One more observation: The first time I run the client after installing 2.2, I see the splash screen, then it exits (logging the exception). Subsequent runs of the client don't show the splash screen (or if they do, it disappears so quickly that I don't see it).

The only other clue is that there are no config changes ... The whole HTTP server is different.

I meant that there are no changes to the configuration files. Not what software is used - you know about that!

 

[tlhackque]

It seems to use SDDL (A;;GX;;;S-1-1-0). Any reason for not just using "user=Everyone" which seems to translate to SDDL (A;;GX;;;WD)? "WD" should be the same as "S-1-1-0" as far as I understand. It would be easier to understand the code.

The problem with using "Everyone" is that it's a localized group name. The group name in the French locale is "Tout le Monde"; it's something else in German. The SID is language-independent.

 

[henso]

I'm not familiar with the .Net HTTP server

Looking at the code it seems we don't use those ports. Port 55555 is always used with a service descriptor that is randomly generated which should avoid any conflicts.

It ought to be possible to log whatever arguments are passed to the Microsoft code.

Basically only IP bindings are passed to the Microsoft code.

I meant that there are no changes to the configuration files.

And I was pointing out why the same configuration file could yield different results for you.

The problem with using "Everyone" is that it's a localized group name.

That might be right and I was trying to confirm that was the actual reason. The SDDL "WD" should also be language independent.

 

[henso]

@morpheus_xx
I found some time to analyze this a bit and was able to reproduce the issue.
1. The client cannot bind to any specific IP addresses as long as there is a URLACL reservation. It can bind to the reserved wildcard address though.
2. Removing the reservation lets the client bind to local IP addresses but not public ones unless it is running elevated. With no reservation it cannot bind to the wildcard address though. I tried making various reservations for public IP addresses but nothing seemed to work.
3. The reservation does not seem to be required by the server, because it has the right permissions to do any bindings running as a service.

So for the client we seem to be stuck with either allowing binding to local IP addresses only by removing the reservation or only allow binding to the reserved wildcard address. In the future we might need the wildcard binding to allow plugins like WifiRemote etc. to connect from a remote IP address. So this effectively leaves us with not allowing IP address binding on the client. Can you confirm these findings? Do you know of any other possibilities with OWIN?