Error when starting LogExpert 1.5/5493

Jan 20, 2015 at 8:30 AM
I'm getting th following error when I start LogExpert
I'm on Windows Server 2008 R2 Standard 64-bit
The older LogExpert 1.4.4/4566 worked withou a problem (and still does :-))
Fot both versions I have the 64-bit version of ChilkatDotNet2.dll in place

Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.


SecurityException
at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet)
at System.Security.CodeAccessPermission.Demand()
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)
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)
at ?1?.?1?.LoadConfig(String ?50?)
at LogExpert.PluginRegistry.TryAsFileSystem(Type type)
at LogExpert.PluginRegistry.LoadPlugins()
at LogExpert.PluginRegistry.GetInstance()
at LogExpert.LogWindow..ctor(LogTabWindow parent, String fileName, Boolean isTempFile, LoadingFinishedFx loadingFinishedFx, Boolean forcePersistenceLoading)
at LogExpert.LogTabWindow.AddFileTab(String givenFileName, Boolean isTempFile, String title, LoadingFinishedFx loadingFinishedFx, Boolean forcePersistenceLoading, ILogLineColumnizer preProcessColumnizer, Boolean doNotAddToDockPanel)
at LogExpert.LogTabWindow.AddFileTab(String givenFileName, Boolean isTempFile, String title, LoadingFinishedFx loadingFinishedFx, Boolean forcePersistenceLoading, ILogLineColumnizer preProcessColumnizer)
at LogExpert.LogTabWindow.LogTabWindow_Load(Object sender, EventArgs e)
at System.Windows.Forms.Form.OnLoad(EventArgs e)
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl()
at System.Windows.Forms.Control.WmShowWindow(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Can you help me
Thanks
Jan 23, 2015 at 5:35 AM
Nobody experienced the same problem with this version??
Coordinator
Jan 25, 2015 at 1:55 PM
Did you start LogExpert from a network drive?
Jan 27, 2015 at 6:16 AM
Yes I did but I always did that in the past without problems.
I can still do that with the older LogExpert 1.4.4/4566
Jan 29, 2015 at 6:53 PM
I encounter the same issue : can't execute logexpert from a network share.
Feb 19, 2015 at 7:08 AM
@HagenRaab: no solution yet for this problem?
I would like to use the latest version of LogExpert but now I'm forced to use an older version because of this
Coordinator
Feb 23, 2015 at 4:03 PM
I remember that I wasn't able to start LogExpert from network drives from the very beginning on. So I never cared about this since then. I am actually a bit surprised that it currently works with the 1.4 (tested it).

I don't know what to do to make it work again with 1.5. The whole .NET assembly signing and security stuff is a bit confusing, IMHO. Specifically when using unsigned 3rd party stuff (which I do). If someone has a clue, please raise your hand. :)
Feb 25, 2015 at 5:32 AM
Damn ... Then I'm stuck and will have to keep using the older LogExpert version.
Thanks anyway
Mar 7, 2015 at 5:36 PM
I’m raising my hand. I will try to shed some light on this.
The specific exception posted above is caused by the fact that the PLUGINS folder contains a file system type plugin that is trying to open some file and this file access is not permitted by the current CAS (Code Access Security) policy in .NET 2.
When a stand-alone assembly is started the application domain is assigned a trust policy. The policy "code group" is based on where the assembly is located. On the local hard drive the MyComputer code group is used. When it is located on a (mapped) network drive, and the CLR was able to determine that the server belongs to the local Intranet, the Intranet code group is used.
The default local machine CAS policy in .NET 2 is that an application in the MyComputer code group is “full trust”. That is, the CLR will not impose any CAS permissions restricting what resources the assembly may access. The other code groups have different CAS permissions restricting what resources an assembly is permitted to access. In the Intranet code group file access (FileIOPermission) is restricted in the way that code is only granted read-only permission to the folder where the assembly is located. All other paths are denied.
If I create a PLUGINS folder in my LogExpert folder on a network drive and copy the SftpFileSystem.dll I get the exception. The cause is that SftpFileSystem.dll is trying to access its configuration file sftpfilesystem.cfg in %APPDATA%\LogExpert. Access to this folder will be blocked when running in any other zone than MyComputer.
The question then becomes how to fix this?
If you don’t need the SftpFileSystem plug-in delete it, and every other plugin using a configuration file, from the PLUGINS folder! If any plugin accessing a configuration file is needed an administrator has to grant the required permissions (read and write access to the %APPDATA%\LogExpert folder) by editing the local machine CAS policy. At a minimum a custom code group specifically for LogExpert can be added granting it permission to access its local configuration folder.
Mar 9, 2015 at 7:17 AM
Hey Exterminator,

Thanks for this info but when I look @the %APPDATA%\LogExpert (appdata\Roaming\Logexpert) the I see that all groups/users have full access to this folder so ??

@HagenRaab: isn't there some possibility to put all files in the LogExpert root-directory? That way this problem should not exist (I guess)
Coordinator
Apr 1, 2015 at 1:50 PM
Writing app/config data into the application's directory is bad style and unrecommended since mid 90ies. :)
Would also have some disadvantages:
  • multiple users could not share a network located LogExpert installation
  • write access would be required to the program directory (AFAIK this is not always granted on Windows).