Hi Ken,
Security is really a big topic in .NET programming and we also need to
research much to provide some idea. Bypassing it in registry is not a good
method since a basic idea for .NET is to store info in assembly manifest
instead of registry keys.
Anyway, I am glad that the probem is resolved. If there are any more
questions, please post in the group. Thanks very much.
Best regards,
Yanhong Huang
Microsoft Online Partner Support
Get Secure! ¨C
www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
!Reply-To: "Ken Varn" <va***@diebold.com>
!From: "Ken Varn" <va***@diebold.com>
!References: <uK**************@TK2MSFTNGP12.phx.gbl>
<Od**************@TK2MSFTNGP11.phx.gbl>
<#E**************@TK2MSFTNGP12.phx.gbl>
<eE**************@TK2MSFTNGP11.phx.gbl>
!Subject: Re: Help! Debugger reporting System.IO.FIleLoadException.
!Date: Mon, 14 Jul 2003 17:03:58 -0400
!Lines: 136
!Organization: Diebold Inc.
!X-Priority: 3
!X-MSMail-Priority: Normal
!X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
!X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
!Message-ID: <eA**************@TK2MSFTNGP11.phx.gbl>
!Newsgroups:
microsoft.public.dotnet.languages.csharp,microsoft .public.dotnet.languages.v
c,microsoft.public.vsnet.debugging
!NNTP-Posting-Host: 204.151.249.23
!Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP11.phx.gbl
!Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.vc:26143
microsoft.public.vsnet.debugging:2811
microsoft.public.dotnet.languages.csharp:169046
!X-Tomcat-NG: microsoft.public.dotnet.languages.csharp
!
!I tried to run CASPOL and disabled all .NET security and that seemed to fix
!the problem. It seems strange however that the security is so tight for
C#,
!but not for C++. I have had a whole slew of issues regarding remote
!debugging. A lot of other security restrictions are a big pain and I wish
!there was an option to bypass all of them with some sort of registry
setting
!or something.
!
!--
!-----------------------------------
!Ken Varn
!Senior Software Engineer
!Diebold Inc.
!va***@diebold.com
!-----------------------------------
!"Mark Pearce" <ev**@bay.com> wrote in message
!news:eE****************@TK2MSFTNGP11.phx.gbl...
!> Hi Ken,
!>
!> Sorry, but I know absolutely nothing about managed C++ and how
permissions
!> work in that environment. Are you doing that remote debugging in the same
!> way, i.e. by launching the remote app from within Visual Studio? Or are
!you
!> launching it directly on the remote pc and attaching a debugger, in which
!> case the permissions issue doesn't apply?
!>
!> Regards,
!>
!> Mark
!> --
!> Author of "Comprehensive VB .NET Debugging"
!>
http://www.apress.com/book/bookDisplay.html?bID=128
!>
!>
!> "Ken Varn" <va***@diebold.com> wrote in message
!> news:#E**************@TK2MSFTNGP12.phx.gbl...
!> Your explanation makes sense, however the twist is that I able to
remotely
!> debug my managed C++ application that uses the same DLL and it does not
!> produce this exception. What's with that?
!>
!>
!>
!> --
!> -----------------------------------
!> Ken Varn
!> Senior Software Engineer
!> Diebold Inc.
!>
va***@diebold.com
!> -----------------------------------
!> "Mark Pearce" <ev**@bay.com> wrote in message
!> news:Od**************@TK2MSFTNGP11.phx.gbl...
!> > Hi Ken,
!> >
!> > If you're running (and remote debugging) your app from a local network
!> > share, then I suspect that you're running into a permissions issue.
!> Programs
!> > that run on the CLR use something called code access security (CAS),
!which
!> > assigns trust based upon evidence it can gather from the code itself.
!This
!> > evidence is then compared against the security policy, and a permission
!> > grant is generated.
!> >
!> > Part of the evidence used is the security zone where the code is
!located.
!> > When you run the code from your local machine, this will be the
!MyComputer
!> > zone, but when you run it off from a server (or even a server share
!mapped
!> > to a drive on your machine), it will be LocalIntranet. By
!> > default, any code that is run from the MyComputer zone will get a
!> permission
!> > set of FullTrust (un-restricted permission to do anything it pleases).
!> > However, there is a more restrictive policy placed on LocalIntranet
!> > assemblies.
!> >
!> > You probably can't get an exception stack trace because it's not your
!app
!> > that's throwing the exception, it's the CLR.
!> >
!> > A temporary method of solving this issue is to simply give the
!> LocalIntranet
!> > zone more trust. This can be done in the .NET Framework Configuration
!> > control panel applet. A permanent solution is to modify your security
!> policy
!> > to give FullTrust to all assemblies signed with your key.
!> >
!> > HTH,
!> >
!> > Mark
!> > --
!> > Author of "Comprehensive VB .NET Debugging"
!> >
http://www.apress.com/book/bookDisplay.html?bID=128
!> >
!> >
!> > "Ken Varn" <va***@diebold.com> wrote in message
!> > news:uK**************@TK2MSFTNGP12.phx.gbl...
!> > I am trying to remote debug a C# application but the debugger is
!reporting
!> > the following exception:
!> >
!> > An unhandled exception of type 'System.IO.FileLoadException' occurred
in
!> > Unknown Module.
!> > Additional information: Unverifiable assembly 'FrameGrabber' failed
!policy
!> > check.
!> >
!> > The FrameGrabber assembly is a C++ managed DLL.
!> >
!> > I cannot get a stack trace on the exception in the debugger.
!> > I have seen this occur when a C++ managed DLL cannot locate an
unmanaged
!> > library
!> > dependency.
!> >
!> > The weird thing is that I do not get this exception when I run my
!> > application without the debugger.
!> >
!> > I have used the "Depends" tool to check the DLL and found no missing
!DLLs.
!> > Can someone help me out on what I can
!> > do to locate the cause of this exception?
!> >
!> > --
!> > -----------------------------------
!> > Ken Varn
!> > Senior Software Engineer
!> > Diebold Inc.
!> >
va***@diebold.com
!> > -----------------------------------
!> >
!> >
!> >
!>
!>
!>
!
!
!
