news:1155049377.143124.19420@i42g2000cwa.googlegroups.com...
> Hi All,
>
> Environment:
>
> - Windows 2000 Server
> - .NET 2.0
>
> I have an unmanaged C++ application that references a mixed mode image
> DLL (mixed managed and unmanaged). Under .NET 1.1 we could trust the
> dll (the mixed mode dll) by running the following command line:
>
> caspol.exe -polchgprompt off -machine -addgroup 1 -url "file://<UNC
> path to dll>\mixedMode.dll" FullTrust -name "GroupName" -polchgprompt
> on
>
> Then running the application from a UNC path would succeed.
>
> We recompiled the DLL under VS2005 and .NET 2.0 and now just trusting
> the dll as above (running the .NET 2.0 version of CASPOL) is not
> sufficient. When we run the application we receive a security error.
> Only turning security off "caspol -s off" or trusting the entire path
> using the command line below allows the application to run.
>
> caspol.exe -m -ag 1 -url file://<UNC path to dll>/* FullTrust
>
> However, when running the .NET 2.0 version of the application on a
> Windows XP Pro machine, the first caspol command line is sufficient
> (i.e. trusting the actual DLL).
>
> So the situation is:
> - Windows 2000 Server box runs .NET 1.1 version of app when DLL is
> trusted
> - Windows 2000 Server box does NOT run .NET 2.0 version of app when DLL
> is trusted
> - Windows 2000 Server box runs .NET 2.0 version of app when entire UNC
> path is trusted
> - Windows 2000 Server box runs .NET 2.0 version of app when CAS is
> disabled (caspol -s off)
> - Windows XP Pro box runs .NET 1.1 version of app when DLL is trusted
> - Windows XP Pro box runs .NET 2.0 version of app when DLL is trusted
>
> Does anyone know why CAS on a Windows 2000 Server box would behave
> differently to a Windows XP box when using .NET 2.0 apps? The mixed
> mode DLL is not signed.
>
> Thanks,
> D.
>

> Is your application being deployed with a config file?  If so, what's in it,
> and has it changed any between the 1.1 and 2.0 versions?  Also, could you
> please provide the full exception details (including call stack listing), as
> returned by its ToString method?
>
>
>
> <daniel.ro***@gmail.com> wrote in message
> news:1155049377.143124.19420@i42g2000cwa.googlegroups.com...
> > Hi All,
> >
> > Environment:
> >
> > - Windows 2000 Server
> > - .NET 2.0
> >
> > I have an unmanaged C++ application that references a mixed mode image
> > DLL (mixed managed and unmanaged). Under .NET 1.1 we could trust the
> > dll (the mixed mode dll) by running the following command line:
> >
> > caspol.exe -polchgprompt off -machine -addgroup 1 -url "file://<UNC
> > path to dll>\mixedMode.dll" FullTrust -name "GroupName" -polchgprompt
> > on
> >
> > Then running the application from a UNC path would succeed.
> >
> > We recompiled the DLL under VS2005 and .NET 2.0 and now just trusting
> > the dll as above (running the .NET 2.0 version of CASPOL) is not
> > sufficient. When we run the application we receive a security error.
> > Only turning security off "caspol -s off" or trusting the entire path
> > using the command line below allows the application to run.
> >
> > caspol.exe -m -ag 1 -url file://<UNC path to dll>/* FullTrust
> >
> > However, when running the .NET 2.0 version of the application on a
> > Windows XP Pro machine, the first caspol command line is sufficient
> > (i.e. trusting the actual DLL).
> >
> > So the situation is:
> > - Windows 2000 Server box runs .NET 1.1 version of app when DLL is
> > trusted
> > - Windows 2000 Server box does NOT run .NET 2.0 version of app when DLL
> > is trusted
> > - Windows 2000 Server box runs .NET 2.0 version of app when entire UNC
> > path is trusted
> > - Windows 2000 Server box runs .NET 2.0 version of app when CAS is
> > disabled (caspol -s off)
> > - Windows XP Pro box runs .NET 1.1 version of app when DLL is trusted
> > - Windows XP Pro box runs .NET 2.0 version of app when DLL is trusted
> >
> > Does anyone know why CAS on a Windows 2000 Server box would behave
> > differently to a Windows XP box when using .NET 2.0 apps? The mixed
> > mode DLL is not signed.
> >
> > Thanks,
> > D.
> >

> Hi Nicole,
>
> The Application is not deployed with a .config file.
>
> Unfortunately, because the app is unmanaged and the security error
> occurs when loading the mixed mode DLL we don't have a clean error
> message. We've been meaning to look into a clean way to handle this
> error but at this point the error dialog is not useful being a generic
> "Error Occurred at memory address etc.". We do get some umanaged stack
> information but it mostly shows the OS attempting to load the DLL etc.
> I will post that stack information soon, in case it's useful.
>
> Any other ideas?
>
> Thanks,
> Danny
>
> Nicole Calinoiu wrote:
> > Is your application being deployed with a config file?  If so, what's in it,
> > and has it changed any between the 1.1 and 2.0 versions?  Also, could you
> > please provide the full exception details (including call stack listing), as
> > returned by its ToString method?
> >
> >
> >
> > <daniel.ro***@gmail.com> wrote in message
> > news:1155049377.143124.19420@i42g2000cwa.googlegroups.com...
> > > Hi All,
> > >
> > > Environment:
> > >
> > > - Windows 2000 Server
> > > - .NET 2.0
> > >
> > > I have an unmanaged C++ application that references a mixed mode image
> > > DLL (mixed managed and unmanaged). Under .NET 1.1 we could trust the
> > > dll (the mixed mode dll) by running the following command line:
> > >
> > > caspol.exe -polchgprompt off -machine -addgroup 1 -url "file://<UNC
> > > path to dll>\mixedMode.dll" FullTrust -name "GroupName" -polchgprompt
> > > on
> > >
> > > Then running the application from a UNC path would succeed.
> > >
> > > We recompiled the DLL under VS2005 and .NET 2.0 and now just trusting
> > > the dll as above (running the .NET 2.0 version of CASPOL) is not
> > > sufficient. When we run the application we receive a security error.
> > > Only turning security off "caspol -s off" or trusting the entire path
> > > using the command line below allows the application to run.
> > >
> > > caspol.exe -m -ag 1 -url file://<UNC path to dll>/* FullTrust
> > >
> > > However, when running the .NET 2.0 version of the application on a
> > > Windows XP Pro machine, the first caspol command line is sufficient
> > > (i.e. trusting the actual DLL).
> > >
> > > So the situation is:
> > > - Windows 2000 Server box runs .NET 1.1 version of app when DLL is
> > > trusted
> > > - Windows 2000 Server box does NOT run .NET 2.0 version of app when DLL
> > > is trusted
> > > - Windows 2000 Server box runs .NET 2.0 version of app when entire UNC
> > > path is trusted
> > > - Windows 2000 Server box runs .NET 2.0 version of app when CAS is
> > > disabled (caspol -s off)
> > > - Windows XP Pro box runs .NET 1.1 version of app when DLL is trusted
> > > - Windows XP Pro box runs .NET 2.0 version of app when DLL is trusted
> > >
> > > Does anyone know why CAS on a Windows 2000 Server box would behave
> > > differently to a Windows XP box when using .NET 2.0 apps? The mixed
> > > mode DLL is not signed.
> > >
> > > Thanks,
> > > D.
> > >

"emu" <daniel.ro***@gmail.com> wrote in message
news:1155097946.796628.291510@i42g2000cwa.googlegroups.com...
> I've included two stack traces, the first is when the DLL is granted
> fulltrust using CASPOL and the second is when the DLL is not trusted
> and neither is the path (and thus should fail to load). I didn't
> included the entire stack but if it's helpful, I can provide it (it's
> all stuff on the unmanaged and non-microsoft side).
>
> DLL FullTrust
> -------------------------
>
> <EXCEPTION code="E0434F4D" addr="7C59BC3F" date="08/09/06"
> time="00:18:25" code_desc="<unkown exception>" more_desc="">
> <STACKENTRY decl="RaiseException" decl_offset="+86" srcfile=""
> module="KERNEL32" base="7c570000" />
> <STACKENTRY decl="DllCanUnloadNowInternal" decl_offset="+14249"
> srcfile="" module="mscorwks" base="79e70000" />
> <STACKENTRY decl="GetAddrOfContractShutoffFlag" decl_offset="+42967"
> srcfile="" module="mscorwks" base="79e70000" />
> <STACKENTRY decl="GetAddrOfContractShutoffFlag" decl_offset="+43136"
> srcfile="" module="mscorwks" base="79e70000" />
> <STACKENTRY decl="GetAddrOfContractShutoffFlag" decl_offset="+43147"
> srcfile="" module="mscorwks" base="79e70000" />
> </EXCEPTION>
>
> DLL No Trust
> ------------------------
> <EXCEPTION code="E0434F4D" addr="7C59BC3F" date="08/08/06"
> time="23:53:12" code_desc="<unkown exception>" more_desc="">
> <STACKENTRY decl="RaiseException" decl_offset="+86" srcfile=""
> module="KERNEL32" base="7c570000" />
> <STACKENTRY decl="DllCanUnloadNowInternal" decl_offset="+14249"
> srcfile="" module="mscorwks" base="79e70000" />
> <STACKENTRY decl="DllCanUnloadNowInternal" decl_offset="+14868"
> srcfile="" module="mscorwks" base="79e70000" />
> <STACKENTRY decl="CorDllMainForThunk" decl_offset="+195" srcfile=""
> module="mscorwks" base="79e70000" />
> <STACKENTRY decl="CorDllMainWorker" decl_offset="+188" srcfile=""
> module="mscoree" base="79000000" />
> <STACKENTRY decl="GetTargetForVTableEntry" decl_offset="+34" srcfile=""
> module="mscoree" base="79000000" />
>
> ..... Some of the stack omitted for brevity.
>
>
> Very different stack traces, so obviously code is following a different
> path when the DLL is granted fulltrust. Perhaps something else has to
> be done on a Windows 2000 Server machine to enable CAS to allow the DLL
> is be loaded???
>
> Any thoughts anyone?
>
> Thanks,
> D.
>
>
> emu wrote:
>> Hi Nicole,
>>
>> The Application is not deployed with a .config file.
>>
>> Unfortunately, because the app is unmanaged and the security error
>> occurs when loading the mixed mode DLL we don't have a clean error
>> message. We've been meaning to look into a clean way to handle this
>> error but at this point the error dialog is not useful being a generic
>> "Error Occurred at memory address etc.". We do get some umanaged stack
>> information but it mostly shows the OS attempting to load the DLL etc.
>> I will post that stack information soon, in case it's useful.
>>
>> Any other ideas?
>>
>> Thanks,
>> Danny
>>
>> Nicole Calinoiu wrote:
>> > Is your application being deployed with a config file?  If so, what's
>> > in it,
>> > and has it changed any between the 1.1 and 2.0 versions?  Also, could
>> > you
>> > please provide the full exception details (including call stack
>> > listing), as
>> > returned by its ToString method?
>> >
>> >
>> >
>> > <daniel.ro***@gmail.com> wrote in message
>> > news:1155049377.143124.19420@i42g2000cwa.googlegroups.com...
>> > > Hi All,
>> > >
>> > > Environment:
>> > >
>> > > - Windows 2000 Server
>> > > - .NET 2.0
>> > >
>> > > I have an unmanaged C++ application that references a mixed mode
>> > > image
>> > > DLL (mixed managed and unmanaged). Under .NET 1.1 we could trust the
>> > > dll (the mixed mode dll) by running the following command line:
>> > >
>> > > caspol.exe -polchgprompt off -machine -addgroup 1 -url "file://<UNC
>> > > path to dll>\mixedMode.dll" FullTrust -name "GroupName" -polchgprompt
>> > > on
>> > >
>> > > Then running the application from a UNC path would succeed.
>> > >
>> > > We recompiled the DLL under VS2005 and .NET 2.0 and now just trusting
>> > > the dll as above (running the .NET 2.0 version of CASPOL) is not
>> > > sufficient. When we run the application we receive a security error.
>> > > Only turning security off "caspol -s off" or trusting the entire path
>> > > using the command line below allows the application to run.
>> > >
>> > > caspol.exe -m -ag 1 -url file://<UNC path to dll>/* FullTrust
>> > >
>> > > However, when running the .NET 2.0 version of the application on a
>> > > Windows XP Pro machine, the first caspol command line is sufficient
>> > > (i.e. trusting the actual DLL).
>> > >
>> > > So the situation is:
>> > > - Windows 2000 Server box runs .NET 1.1 version of app when DLL is
>> > > trusted
>> > > - Windows 2000 Server box does NOT run .NET 2.0 version of app when
>> > > DLL
>> > > is trusted
>> > > - Windows 2000 Server box runs .NET 2.0 version of app when entire
>> > > UNC
>> > > path is trusted
>> > > - Windows 2000 Server box runs .NET 2.0 version of app when CAS is
>> > > disabled (caspol -s off)
>> > > - Windows XP Pro box runs .NET 1.1 version of app when DLL is trusted
>> > > - Windows XP Pro box runs .NET 2.0 version of app when DLL is trusted
>> > >
>> > > Does anyone know why CAS on a Windows 2000 Server box would behave
>> > > differently to a Windows XP box when using .NET 2.0 apps? The mixed
>> > > mode DLL is not signed.
>> > >
>> > > Thanks,
>> > > D.
>> > >
>

> What about the exception type and message?
>
>
> "emu" <daniel.ro***@gmail.com> wrote in message
> news:1155097946.796628.291510@i42g2000cwa.googlegroups.com...
> > I've included two stack traces, the first is when the DLL is granted
> > fulltrust using CASPOL and the second is when the DLL is not trusted
> > and neither is the path (and thus should fail to load). I didn't
> > included the entire stack but if it's helpful, I can provide it (it's
> > all stuff on the unmanaged and non-microsoft side).
> >
> > DLL FullTrust
> > -------------------------
> >
> > <EXCEPTION code="E0434F4D" addr="7C59BC3F" date="08/09/06"
> > time="00:18:25" code_desc="<unkown exception>" more_desc="">
> > <STACKENTRY decl="RaiseException" decl_offset="+86" srcfile=""
> > module="KERNEL32" base="7c570000" />
> > <STACKENTRY decl="DllCanUnloadNowInternal" decl_offset="+14249"
> > srcfile="" module="mscorwks" base="79e70000" />
> > <STACKENTRY decl="GetAddrOfContractShutoffFlag" decl_offset="+42967"
> > srcfile="" module="mscorwks" base="79e70000" />
> > <STACKENTRY decl="GetAddrOfContractShutoffFlag" decl_offset="+43136"
> > srcfile="" module="mscorwks" base="79e70000" />
> > <STACKENTRY decl="GetAddrOfContractShutoffFlag" decl_offset="+43147"
> > srcfile="" module="mscorwks" base="79e70000" />
> > </EXCEPTION>
> >
> > DLL No Trust
> > ------------------------
> > <EXCEPTION code="E0434F4D" addr="7C59BC3F" date="08/08/06"
> > time="23:53:12" code_desc="<unkown exception>" more_desc="">
> > <STACKENTRY decl="RaiseException" decl_offset="+86" srcfile=""
> > module="KERNEL32" base="7c570000" />
> > <STACKENTRY decl="DllCanUnloadNowInternal" decl_offset="+14249"
> > srcfile="" module="mscorwks" base="79e70000" />
> > <STACKENTRY decl="DllCanUnloadNowInternal" decl_offset="+14868"
> > srcfile="" module="mscorwks" base="79e70000" />
> > <STACKENTRY decl="CorDllMainForThunk" decl_offset="+195" srcfile=""
> > module="mscorwks" base="79e70000" />
> > <STACKENTRY decl="CorDllMainWorker" decl_offset="+188" srcfile=""
> > module="mscoree" base="79000000" />
> > <STACKENTRY decl="GetTargetForVTableEntry" decl_offset="+34" srcfile=""
> > module="mscoree" base="79000000" />
> >
> > ..... Some of the stack omitted for brevity.
> >
> >
> > Very different stack traces, so obviously code is following a different
> > path when the DLL is granted fulltrust. Perhaps something else has to
> > be done on a Windows 2000 Server machine to enable CAS to allow the DLL
> > is be loaded???
> >
> > Any thoughts anyone?
> >
> > Thanks,
> > D.
> >
> >
> > emu wrote:
> >> Hi Nicole,
> >>
> >> The Application is not deployed with a .config file.
> >>
> >> Unfortunately, because the app is unmanaged and the security error
> >> occurs when loading the mixed mode DLL we don't have a clean error
> >> message. We've been meaning to look into a clean way to handle this
> >> error but at this point the error dialog is not useful being a generic
> >> "Error Occurred at memory address etc.". We do get some umanaged stack
> >> information but it mostly shows the OS attempting to load the DLL etc.
> >> I will post that stack information soon, in case it's useful.
> >>
> >> Any other ideas?
> >>
> >> Thanks,
> >> Danny
> >>
> >> Nicole Calinoiu wrote:
> >> > Is your application being deployed with a config file?  If so, what's
> >> > in it,
> >> > and has it changed any between the 1.1 and 2.0 versions?  Also, could
> >> > you
> >> > please provide the full exception details (including call stack
> >> > listing), as
> >> > returned by its ToString method?
> >> >
> >> >
> >> >
> >> > <daniel.ro***@gmail.com> wrote in message
> >> > news:1155049377.143124.19420@i42g2000cwa.googlegroups.com...
> >> > > Hi All,
> >> > >
> >> > > Environment:
> >> > >
> >> > > - Windows 2000 Server
> >> > > - .NET 2.0
> >> > >
> >> > > I have an unmanaged C++ application that references a mixed mode
> >> > > image
> >> > > DLL (mixed managed and unmanaged). Under .NET 1.1 we could trust the
> >> > > dll (the mixed mode dll) by running the following command line:
> >> > >
> >> > > caspol.exe -polchgprompt off -machine -addgroup 1 -url "file://<UNC
> >> > > path to dll>\mixedMode.dll" FullTrust -name "GroupName" -polchgprompt
> >> > > on
> >> > >
> >> > > Then running the application from a UNC path would succeed.
> >> > >
> >> > > We recompiled the DLL under VS2005 and .NET 2.0 and now just trusting
> >> > > the dll as above (running the .NET 2.0 version of CASPOL) is not
> >> > > sufficient. When we run the application we receive a security error.
> >> > > Only turning security off "caspol -s off" or trusting the entire path
> >> > > using the command line below allows the application to run.
> >> > >
> >> > > caspol.exe -m -ag 1 -url file://<UNC path to dll>/* FullTrust
> >> > >
> >> > > However, when running the .NET 2.0 version of the application on a
> >> > > Windows XP Pro machine, the first caspol command line is sufficient
> >> > > (i.e. trusting the actual DLL).
> >> > >
> >> > > So the situation is:
> >> > > - Windows 2000 Server box runs .NET 1.1 version of app when DLL is
> >> > > trusted
> >> > > - Windows 2000 Server box does NOT run .NET 2.0 version of app when
> >> > > DLL
> >> > > is trusted
> >> > > - Windows 2000 Server box runs .NET 2.0 version of app when entire
> >> > > UNC
> >> > > path is trusted
> >> > > - Windows 2000 Server box runs .NET 2.0 version of app when CAS is
> >> > > disabled (caspol -s off)
> >> > > - Windows XP Pro box runs .NET 1.1 version of app when DLL is trusted
> >> > > - Windows XP Pro box runs .NET 2.0 version of app when DLL is trusted
> >> > >
> >> > > Does anyone know why CAS on a Windows 2000 Server box would behave
> >> > > differently to a Windows XP box when using .NET 2.0 apps? The mixed
> >> > > mode DLL is not signed.
> >> > >
> >> > > Thanks,
> >> > > D.
> >> > >
> >

> Well, unfortunately, I can't really get access to that information. The
> dialog displayed when the error returned basically contains the same
> information you see in the summary info in the stack traces I provided.
> The dialog says something like:
>
> Unhandled Exception! ExpCode: E0434F4D ExpFlags: 1 ExpAddress: 7C59BC3F
>
> I believe, although I'm not certain, that E0434F4D simply indicates a
> try block failed and an exception occurred.
>
> Thoughts?
>
>
> Nicole Calinoiu wrote:
> > What about the exception type and message?
> >
> >
> > "emu" <daniel.ro***@gmail.com> wrote in message
> > news:1155097946.796628.291510@i42g2000cwa.googlegroups.com...
> > > I've included two stack traces, the first is when the DLL is granted
> > > fulltrust using CASPOL and the second is when the DLL is not trusted
> > > and neither is the path (and thus should fail to load). I didn't
> > > included the entire stack but if it's helpful, I can provide it (it's
> > > all stuff on the unmanaged and non-microsoft side).
> > >
> > > DLL FullTrust
> > > -------------------------
> > >
> > > <EXCEPTION code="E0434F4D" addr="7C59BC3F" date="08/09/06"
> > > time="00:18:25" code_desc="<unkown exception>" more_desc="">
> > > <STACKENTRY decl="RaiseException" decl_offset="+86" srcfile=""
> > > module="KERNEL32" base="7c570000" />
> > > <STACKENTRY decl="DllCanUnloadNowInternal" decl_offset="+14249"
> > > srcfile="" module="mscorwks" base="79e70000" />
> > > <STACKENTRY decl="GetAddrOfContractShutoffFlag" decl_offset="+42967"
> > > srcfile="" module="mscorwks" base="79e70000" />
> > > <STACKENTRY decl="GetAddrOfContractShutoffFlag" decl_offset="+43136"
> > > srcfile="" module="mscorwks" base="79e70000" />
> > > <STACKENTRY decl="GetAddrOfContractShutoffFlag" decl_offset="+43147"
> > > srcfile="" module="mscorwks" base="79e70000" />
> > > </EXCEPTION>
> > >
> > > DLL No Trust
> > > ------------------------
> > > <EXCEPTION code="E0434F4D" addr="7C59BC3F" date="08/08/06"
> > > time="23:53:12" code_desc="<unkown exception>" more_desc="">
> > > <STACKENTRY decl="RaiseException" decl_offset="+86" srcfile=""
> > > module="KERNEL32" base="7c570000" />
> > > <STACKENTRY decl="DllCanUnloadNowInternal" decl_offset="+14249"
> > > srcfile="" module="mscorwks" base="79e70000" />
> > > <STACKENTRY decl="DllCanUnloadNowInternal" decl_offset="+14868"
> > > srcfile="" module="mscorwks" base="79e70000" />
> > > <STACKENTRY decl="CorDllMainForThunk" decl_offset="+195" srcfile=""
> > > module="mscorwks" base="79e70000" />
> > > <STACKENTRY decl="CorDllMainWorker" decl_offset="+188" srcfile=""
> > > module="mscoree" base="79000000" />
> > > <STACKENTRY decl="GetTargetForVTableEntry" decl_offset="+34" srcfile=""
> > > module="mscoree" base="79000000" />
> > >
> > > ..... Some of the stack omitted for brevity.
> > >
> > >
> > > Very different stack traces, so obviously code is following a different
> > > path when the DLL is granted fulltrust. Perhaps something else has to
> > > be done on a Windows 2000 Server machine to enable CAS to allow the DLL
> > > is be loaded???
> > >
> > > Any thoughts anyone?
> > >
> > > Thanks,
> > > D.
> > >
> > >
> > > emu wrote:
> > >> Hi Nicole,
> > >>
> > >> The Application is not deployed with a .config file.
> > >>
> > >> Unfortunately, because the app is unmanaged and the security error
> > >> occurs when loading the mixed mode DLL we don't have a clean error
> > >> message. We've been meaning to look into a clean way to handle this
> > >> error but at this point the error dialog is not useful being a generic
> > >> "Error Occurred at memory address etc.". We do get some umanaged stack
> > >> information but it mostly shows the OS attempting to load the DLL etc.
> > >> I will post that stack information soon, in case it's useful.
> > >>
> > >> Any other ideas?
> > >>
> > >> Thanks,
> > >> Danny
> > >>
> > >> Nicole Calinoiu wrote:
> > >> > Is your application being deployed with a config file?  If so, what's
> > >> > in it,
> > >> > and has it changed any between the 1.1 and 2.0 versions?  Also, could
> > >> > you
> > >> > please provide the full exception details (including call stack
> > >> > listing), as
> > >> > returned by its ToString method?
> > >> >
> > >> >
> > >> >
> > >> > <daniel.ro***@gmail.com> wrote in message
> > >> > news:1155049377.143124.19420@i42g2000cwa.googlegroups.com...
> > >> > > Hi All,
> > >> > >
> > >> > > Environment:
> > >> > >
> > >> > > - Windows 2000 Server
> > >> > > - .NET 2.0
> > >> > >
> > >> > > I have an unmanaged C++ application that references a mixed mode
> > >> > > image
> > >> > > DLL (mixed managed and unmanaged). Under .NET 1.1 we could trust the
> > >> > > dll (the mixed mode dll) by running the following command line:
> > >> > >
> > >> > > caspol.exe -polchgprompt off -machine -addgroup 1 -url "file://<UNC
> > >> > > path to dll>\mixedMode.dll" FullTrust -name "GroupName" -polchgprompt
> > >> > > on
> > >> > >
> > >> > > Then running the application from a UNC path would succeed.
> > >> > >
> > >> > > We recompiled the DLL under VS2005 and .NET 2.0 and now just trusting
> > >> > > the dll as above (running the .NET 2.0 version of CASPOL) is not
> > >> > > sufficient. When we run the application we receive a security error.
> > >> > > Only turning security off "caspol -s off" or trusting the entire path
> > >> > > using the command line below allows the application to run.
> > >> > >
> > >> > > caspol.exe -m -ag 1 -url file://<UNC path to dll>/* FullTrust
> > >> > >
> > >> > > However, when running the .NET 2.0 version of the application on a
> > >> > > Windows XP Pro machine, the first caspol command line is sufficient
> > >> > > (i.e. trusting the actual DLL).
> > >> > >
> > >> > > So the situation is:
> > >> > > - Windows 2000 Server box runs .NET 1.1 version of app when DLL is
> > >> > > trusted
> > >> > > - Windows 2000 Server box does NOT run .NET 2.0 version of app when
> > >> > > DLL
> > >> > > is trusted
> > >> > > - Windows 2000 Server box runs .NET 2.0 version of app when entire
> > >> > > UNC
> > >> > > path is trusted
> > >> > > - Windows 2000 Server box runs .NET 2.0 version of app when CAS is
> > >> > > disabled (caspol -s off)
> > >> > > - Windows XP Pro box runs .NET 1.1 version of app when DLL is trusted
> > >> > > - Windows XP Pro box runs .NET 2.0 version of app when DLL is trusted
> > >> > >
> > >> > > Does anyone know why CAS on a Windows 2000 Server box would behave
> > >> > > differently to a Windows XP box when using .NET 2.0 apps? The mixed
> > >> > > mode DLL is not signed.
> > >> > >
> > >> > > Thanks,
> > >> > > D.
> > >> > >
> > >

"emu" <daniel.ro***@gmail.com> wrote in message
news:1155131124.610288.28280@i3g2000cwc.googlegroups.com...
> Some additional information. The fusion log shows pretty much the same
> thing whether I trust just the DLL and the app fails to run or I turn
> off security and the app runs correctly. The fusion log says it binds
> to the the mixed mode DLL successfull etc. even when security settings
> cause the app to fail. The only difference I've noticed is that in the
> successful case it shows that System.Xml.dll is being loaded (our mixed
> mode DLL references System.Xml.dll) where as in the failure case it
> never loads System.Xml.dll.
>
> Any other ideas on how to find out more about what is happening during
> the loading of the assemblies and .NET security checks?
>
> Thanks,
> D.
>
>
> emu wrote:
>> Well, unfortunately, I can't really get access to that information. The
>> dialog displayed when the error returned basically contains the same
>> information you see in the summary info in the stack traces I provided.
>> The dialog says something like:
>>
>> Unhandled Exception! ExpCode: E0434F4D ExpFlags: 1 ExpAddress: 7C59BC3F
>>
>> I believe, although I'm not certain, that E0434F4D simply indicates a
>> try block failed and an exception occurred.
>>
>> Thoughts?
>>
>>
>> Nicole Calinoiu wrote:
>> > What about the exception type and message?
>> >
>> >
>> > "emu" <daniel.ro***@gmail.com> wrote in message
>> > news:1155097946.796628.291510@i42g2000cwa.googlegroups.com...
>> > > I've included two stack traces, the first is when the DLL is granted
>> > > fulltrust using CASPOL and the second is when the DLL is not trusted
>> > > and neither is the path (and thus should fail to load). I didn't
>> > > included the entire stack but if it's helpful, I can provide it (it's
>> > > all stuff on the unmanaged and non-microsoft side).
>> > >
>> > > DLL FullTrust
>> > > -------------------------
>> > >
>> > > <EXCEPTION code="E0434F4D" addr="7C59BC3F" date="08/09/06"
>> > > time="00:18:25" code_desc="<unkown exception>" more_desc="">
>> > > <STACKENTRY decl="RaiseException" decl_offset="+86" srcfile=""
>> > > module="KERNEL32" base="7c570000" />
>> > > <STACKENTRY decl="DllCanUnloadNowInternal" decl_offset="+14249"
>> > > srcfile="" module="mscorwks" base="79e70000" />
>> > > <STACKENTRY decl="GetAddrOfContractShutoffFlag" decl_offset="+42967"
>> > > srcfile="" module="mscorwks" base="79e70000" />
>> > > <STACKENTRY decl="GetAddrOfContractShutoffFlag" decl_offset="+43136"
>> > > srcfile="" module="mscorwks" base="79e70000" />
>> > > <STACKENTRY decl="GetAddrOfContractShutoffFlag" decl_offset="+43147"
>> > > srcfile="" module="mscorwks" base="79e70000" />
>> > > </EXCEPTION>
>> > >
>> > > DLL No Trust
>> > > ------------------------
>> > > <EXCEPTION code="E0434F4D" addr="7C59BC3F" date="08/08/06"
>> > > time="23:53:12" code_desc="<unkown exception>" more_desc="">
>> > > <STACKENTRY decl="RaiseException" decl_offset="+86" srcfile=""
>> > > module="KERNEL32" base="7c570000" />
>> > > <STACKENTRY decl="DllCanUnloadNowInternal" decl_offset="+14249"
>> > > srcfile="" module="mscorwks" base="79e70000" />
>> > > <STACKENTRY decl="DllCanUnloadNowInternal" decl_offset="+14868"
>> > > srcfile="" module="mscorwks" base="79e70000" />
>> > > <STACKENTRY decl="CorDllMainForThunk" decl_offset="+195" srcfile=""
>> > > module="mscorwks" base="79e70000" />
>> > > <STACKENTRY decl="CorDllMainWorker" decl_offset="+188" srcfile=""
>> > > module="mscoree" base="79000000" />
>> > > <STACKENTRY decl="GetTargetForVTableEntry" decl_offset="+34"
>> > > srcfile=""
>> > > module="mscoree" base="79000000" />
>> > >
>> > > ..... Some of the stack omitted for brevity.
>> > >
>> > >
>> > > Very different stack traces, so obviously code is following a
>> > > different
>> > > path when the DLL is granted fulltrust. Perhaps something else has to
>> > > be done on a Windows 2000 Server machine to enable CAS to allow the
>> > > DLL
>> > > is be loaded???
>> > >
>> > > Any thoughts anyone?
>> > >
>> > > Thanks,
>> > > D.
>> > >
>> > >
>> > > emu wrote:
>> > >> Hi Nicole,
>> > >>
>> > >> The Application is not deployed with a .config file.
>> > >>
>> > >> Unfortunately, because the app is unmanaged and the security error
>> > >> occurs when loading the mixed mode DLL we don't have a clean error
>> > >> message. We've been meaning to look into a clean way to handle this
>> > >> error but at this point the error dialog is not useful being a
>> > >> generic
>> > >> "Error Occurred at memory address etc.". We do get some umanaged
>> > >> stack
>> > >> information but it mostly shows the OS attempting to load the DLL
>> > >> etc.
>> > >> I will post that stack information soon, in case it's useful.
>> > >>
>> > >> Any other ideas?
>> > >>
>> > >> Thanks,
>> > >> Danny
>> > >>
>> > >> Nicole Calinoiu wrote:
>> > >> > Is your application being deployed with a config file?  If so,
>> > >> > what's
>> > >> > in it,
>> > >> > and has it changed any between the 1.1 and 2.0 versions?  Also,
>> > >> > could
>> > >> > you
>> > >> > please provide the full exception details (including call stack
>> > >> > listing), as
>> > >> > returned by its ToString method?
>> > >> >
>> > >> >
>> > >> >
>> > >> > <daniel.ro***@gmail.com> wrote in message
>> > >> > news:1155049377.143124.19420@i42g2000cwa.googlegroups.com...
>> > >> > > Hi All,
>> > >> > >
>> > >> > > Environment:
>> > >> > >
>> > >> > > - Windows 2000 Server
>> > >> > > - .NET 2.0
>> > >> > >
>> > >> > > I have an unmanaged C++ application that references a mixed mode
>> > >> > > image
>> > >> > > DLL (mixed managed and unmanaged). Under .NET 1.1 we could trust
>> > >> > > the
>> > >> > > dll (the mixed mode dll) by running the following command line:
>> > >> > >
>> > >> > > caspol.exe -polchgprompt off -machine -addgroup 1 -url
>> > >> > > "file://<UNC
>> > >> > > path to dll>\mixedMode.dll" FullTrust -name
>> > >> > > "GroupName" -polchgprompt
>> > >> > > on
>> > >> > >
>> > >> > > Then running the application from a UNC path would succeed.
>> > >> > >
>> > >> > > We recompiled the DLL under VS2005 and .NET 2.0 and now just
>> > >> > > trusting
>> > >> > > the dll as above (running the .NET 2.0 version of CASPOL) is not
>> > >> > > sufficient. When we run the application we receive a security
>> > >> > > error.
>> > >> > > Only turning security off "caspol -s off" or trusting the entire
>> > >> > > path
>> > >> > > using the command line below allows the application to run.
>> > >> > >
>> > >> > > caspol.exe -m -ag 1 -url file://<UNC path to dll>/* FullTrust
>> > >> > >
>> > >> > > However, when running the .NET 2.0 version of the application on
>> > >> > > a
>> > >> > > Windows XP Pro machine, the first caspol command line is
>> > >> > > sufficient
>> > >> > > (i.e. trusting the actual DLL).
>> > >> > >
>> > >> > > So the situation is:
>> > >> > > - Windows 2000 Server box runs .NET 1.1 version of app when DLL
>> > >> > > is
>> > >> > > trusted
>> > >> > > - Windows 2000 Server box does NOT run .NET 2.0 version of app
>> > >> > > when
>> > >> > > DLL
>> > >> > > is trusted
>> > >> > > - Windows 2000 Server box runs .NET 2.0 version of app when
>> > >> > > entire
>> > >> > > UNC
>> > >> > > path is trusted
>> > >> > > - Windows 2000 Server box runs .NET 2.0 version of app when CAS
>> > >> > > is
>> > >> > > disabled (caspol -s off)
>> > >> > > - Windows XP Pro box runs .NET 1.1 version of app when DLL is
>> > >> > > trusted
>> > >> > > - Windows XP Pro box runs .NET 2.0 version of app when DLL is
>> > >> > > trusted
>> > >> > >
>> > >> > > Does anyone know why CAS on a Windows 2000 Server box would
>> > >> > > behave
>> > >> > > differently to a Windows XP box when using .NET 2.0 apps? The
>> > >> > > mixed
>> > >> > > mode DLL is not signed.
>> > >> > >
>> > >> > > Thanks,
>> > >> > > D.
>> > >> > >
>> > >
>