mscorlib.dll error when trying to clean install latest version

[Ian-Highlander 147]

Been away from this forum for a long time, real life taken over for a while lol.

 

I'm having an issue on a clean install on a brand new freshly installed Windows 2008 R2 server. Fully updated, .NET frameworks installed up to 4.7

 

My server crashed and burned badly, so I've had to replace numerous hard drives and rebuild the whole system from scratch. Got everything up and running except Emby and am having some weird issues with it.

 

On a clean install of the latest version it gets to the last stage, copies all the files then I get a Windows appcrash error relating to it and mscorlib.dll however if I close the error screen Emby starts normally and appears to be fine. It also then can close and re-start normally, however I've noticed the service doesn't appear to have been installed and I use that as a pose to the tray icon as I prefer to leave the server logged off (good security practice anyway).

 

I can live with the mscorlib error if it wasn't doing anything in particular to worry about and the system does seem to work, although would prefer not to have any errors at all on a clean system but not having the service is a pain in the rear end. Is there an easy way for me to get the service installed again? Presumably it's just a command line using the .net installutil but can someone give me the specifics required please. Any idea what the crash is and if it's something I can resolve myself at this end?

 

@@Luke perhaps.

 

Server install log attached although it doesn't give much away.

 

Windows event log has these two entries in it:

 

 

Application: MediaBrowser.ServerApplication.exe

Framework Version: v4.0.30319

Description: The process was terminated due to an unhandled exception.

Exception Info: System.IO.IOException

   at System.IO.__Error.WinIOError(Int32, System.String)

   at System.IO.FileStream.Init(System.String, System.IO.FileMode, System.IO.FileAccess, Int32, Boolean, System.IO.FileShare, Int32, System.IO.FileOptions, SECURITY_ATTRIBUTES, System.String, Boolean, Boolean, Boolean)

   at System.IO.FileStream..ctor(System.String, System.IO.FileMode, System.IO.FileAccess, System.IO.FileShare, Int32)

   at Emby.Server.Implementations.Logging.FileLogger..ctor(System.String)

   at Emby.Server.Implementations.Logging.SimpleLogManager.ReloadLogger(MediaBrowser.Model.Logging.LogSeverity)

   at MediaBrowser.ServerApplication.MainStartup.Main()

 

 

 

Faulting application name: MediaBrowser.ServerApplication.exe, version: 3.2.30.0, time stamp: 0x59a45df4

Faulting module name: KERNELBASE.dll, version: 6.1.7601.23864, time stamp: 0x595fa988

Exception code: 0xe0434352

Fault offset: 0x000000000001a06d

Faulting process id: 0x1780

Faulting application start time: 0x01d32666df9a81ae

Faulting application path: C:\Users\iana\AppData\Roaming\Emby-Server\system\MediaBrowser.ServerApplication.exe

Faulting module path: C:\Windows\system32\KERNELBASE.dll

Report Id: 1dacf58b-925a-11e7-ad5f-00248c533b3b

 

server-install.log

[Luke 42085]

If the logger can't even initialize then that means it's not able to open a file with write access underneath the logs folder.

[Ian-Highlander 147]

If the logger can't even initialize then that means it's not able to open a file with write access underneath the logs folder.

Hi Luke, long time no speak and thanks for the quick reply.

 

I'm slightly confused by this as I'm running the installer as administrator on an already administrator (and domain admin) account. The installer creates all the relevant file and directory structures and the Emby process seems to run fine if started manually afterwards.

 

What could cause this?

[Luke 42085]

I'm not sure, never seen this before. I suppose you could try the portable install and see if that's any different.

[Ian-Highlander 147]

I'm not sure, never seen this before. I suppose you could try the portable install and see if that's any different.

Very strange indeed, every other thing I've installed has worked perfectly with no issues and it's a completley clean, fully updated windows server build.

 

Just to eliminate a corrupted user profile or something being the issue (although that's nearly impossible) I just tried the install using a different admin user on a clean user profile that hadn't logged into the server since the rebuild, with EXACTLY the same issue.

 

I'm not sure the portable install will help diagnose this although I'll give it a go, but as I mentioned Emby starts and appears to run once it's past this error. Although the service isn't available, but I can get that installed manually if I have to.

 

What a pain, all the issues I had and all the various bits of software I've had to reinstall and reconfigure, it wasn't Emby that I expected to be the one to give me problems lol.

 

If there's any other help/advice you can offer I'd be grateful for the assistance, failing that I guess I'm stuck fumbling around trying to work it out. If it causes problems and I can't resolve it I'm left with no other choice but to look at alternatives which would royally suck but the missus can't be without her media system much longer, she's climbing the walls as it is 

[Luke 42085]

I do not believe there's an Emby problem here. It seems to be strictly an issue of file permissions. Anyway, try the portable install.

[Luke 42085]

By the way, we haven't tested the .net framework 4.7 yet. I would suggest installing 4.61 as that's what the app is targeting.

[Ian-Highlander 147]

By the way, we haven't tested the .net framework 4.7 yet. I would suggest installing 4.61 as that's what the app is targeting.

This was the key to fixing it, thanks Luke. I had installed 4.6.2 previously as well as 4.7 (which is a Windows Update these days) amongst other earlier versions required by various software.

 

A full install (using the offline installer) of 4.6.1 and another server reboot has resolved the issue, Emby now installs, runs, the service gets installed as expected and no appcrash. This is with no file permission changes either, so definitely not that which was the issue, but the .NET framework version is obviously very specifically targeted and a minor version difference was enough to break it (at least in my instance).

 

Thanks for the quick response as always.

[Luke 42085]

Thanks for the feedback.