64bit problem?

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

64bit problem?

Thiemo.Kellner

Hi all

 

I am at my wits’ end. We developped PowerShell script which uses log4net. I can run the script successfully from a batch file on my laptop but on the server I get

 

Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem'

provider failed.

I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1 :

Exception calling "LoadFile" with "1" argument(s): "The parameter is

incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))"

At line:1 char:1

+ I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1

-stat_activi ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~

    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorExcep

   tion

    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorExceptio

   n,metadata_join_params-thiemo.ps1

 

 

I found http://stackoverflow.com/questions/10249406/powershell-v2-load-a-com-interop-dll which points to a possible problem with mixing 32 dlls in 64 bit PowerShell. As my laptop is 32 and the server 64 bit, I was wondering if this might cause the problem. At least I could pin the line of code where the exception gets thrown: [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

Has anyone an idea?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Reply | Threaded
Open this post in threaded view
|

AW: 64bit problem?

Thiemo.Kellner

I found https://issues.apache.org/jira/browse/LOG4NET-138 . Maybe there is a problem?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: [hidden email] [mailto:[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:36
An: [hidden email]
Betreff: 64bit problem?

 

Hi all

 

I am at my wits’ end. We developped PowerShell script which uses log4net. I can run the script successfully from a batch file on my laptop but on the server I get

 

Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem'

provider failed.

I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1 :

Exception calling "LoadFile" with "1" argument(s): "The parameter is

incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))"

At line:1 char:1

+ I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1

-stat_activi ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~

    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorExcep

   tion

    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorExceptio

   n,metadata_join_params-thiemo.ps1

 

 

I found http://stackoverflow.com/questions/10249406/powershell-v2-load-a-com-interop-dll which points to a possible problem with mixing 32 dlls in 64 bit PowerShell. As my laptop is 32 and the server 64 bit, I was wondering if this might cause the problem. At least I could pin the line of code where the exception gets thrown: [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

Has anyone an idea?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Reply | Threaded
Open this post in threaded view
|

AW: 64bit problem?

Dominik Psenner

To be honest, the error message is rather cryptic to me. What I know is that log4net is not compiled against a specific architecture. If the targeted .NET framework is installed it should work. Have you checked that?

 

Von: [hidden email] [mailto:[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:48
An: [hidden email]
Betreff: AW: 64bit problem?

 

I found https://issues.apache.org/jira/browse/LOG4NET-138 . Maybe there is a problem?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:36
An: [hidden email]
Betreff: 64bit problem?

 

Hi all

 

I am at my wits’ end. We developped PowerShell script which uses log4net. I can run the script successfully from a batch file on my laptop but on the server I get

 

Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem'

provider failed.

I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1 :

Exception calling "LoadFile" with "1" argument(s): "The parameter is

incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))"

At line:1 char:1

+ I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1

-stat_activi ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~

    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorExcep

   tion

    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorExceptio

   n,metadata_join_params-thiemo.ps1

 

 

I found http://stackoverflow.com/questions/10249406/powershell-v2-load-a-com-interop-dll which points to a possible problem with mixing 32 dlls in 64 bit PowerShell. As my laptop is 32 and the server 64 bit, I was wondering if this might cause the problem. At least I could pin the line of code where the exception gets thrown: [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

Has anyone an idea?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Reply | Threaded
Open this post in threaded view
|

AW: 64bit problem?

Thiemo.Kellner

Assuming that on either system the most resent framework gets loaded, on both systems 4.0.30319 is used. However, on the server there are both flavours, 32 and 64 bit. I do not know which one is loaded.

 

I forgot to mention that we use log4net 1.2.13, in case this makes a difference. The powershell version on the server is 3, on the laptop it is 4.

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Dominik Psenner [mailto:[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 15:40
An: 'Log4NET User'
Betreff: AW: 64bit problem?

 

To be honest, the error message is rather cryptic to me. What I know is that log4net is not compiled against a specific architecture. If the targeted .NET framework is installed it should work. Have you checked that?

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:48
An: [hidden email]
Betreff: AW: 64bit problem?

 

I found https://issues.apache.org/jira/browse/LOG4NET-138 . Maybe there is a problem?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:36
An: [hidden email]
Betreff: 64bit problem?

 

Hi all

 

I am at my wits’ end. We developped PowerShell script which uses log4net. I can run the script successfully from a batch file on my laptop but on the server I get

 

Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem'

provider failed.

I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1 :

Exception calling "LoadFile" with "1" argument(s): "The parameter is

incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))"

At line:1 char:1

+ I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1

-stat_activi ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~

    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorExcep

   tion

    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorExceptio

   n,metadata_join_params-thiemo.ps1

 

 

I found http://stackoverflow.com/questions/10249406/powershell-v2-load-a-com-interop-dll which points to a possible problem with mixing 32 dlls in 64 bit PowerShell. As my laptop is 32 and the server 64 bit, I was wondering if this might cause the problem. At least I could pin the line of code where the exception gets thrown: [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

Has anyone an idea?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Reply | Threaded
Open this post in threaded view
|

RE: 64bit problem?

Radovan Raszka

It looks like powershell can’t find where log4net.dll is located. As log4net is platform neutral (compiled as any CPU), I don’t think 32 x 64 bit OS is issue.

Where you have log4net.dll installed? Probably is good idea to put it into GAC.

Or put it into folder where powershell is installed. Key is to find where powershell tried to find log4net.dll – is it possible to discover this info?

Radovan

 

From: [hidden email] [mailto:[hidden email]]
Sent: Thursday, February 26, 2015 4:19 PM
To: [hidden email]
Subject: AW: 64bit problem?

 

Assuming that on either system the most resent framework gets loaded, on both systems 4.0.30319 is used. However, on the server there are both flavours, 32 and 64 bit. I do not know which one is loaded.

 

I forgot to mention that we use log4net 1.2.13, in case this makes a difference. The powershell version on the server is 3, on the laptop it is 4.

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Dominik Psenner [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 15:40
An: 'Log4NET User'
Betreff: AW: 64bit problem?

 

To be honest, the error message is rather cryptic to me. What I know is that log4net is not compiled against a specific architecture. If the targeted .NET framework is installed it should work. Have you checked that?

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:48
An: [hidden email]
Betreff: AW: 64bit problem?

 

I found https://issues.apache.org/jira/browse/LOG4NET-138 . Maybe there is a problem?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:36
An: [hidden email]
Betreff: 64bit problem?

 

Hi all

 

I am at my wits’ end. We developped PowerShell script which uses log4net. I can run the script successfully from a batch file on my laptop but on the server I get

 

Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem'

provider failed.

I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1 :

Exception calling "LoadFile" with "1" argument(s): "The parameter is

incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))"

At line:1 char:1

+ I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1

-stat_activi ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~

    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorExcep

   tion

    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorExceptio

   n,metadata_join_params-thiemo.ps1

 

 

I found http://stackoverflow.com/questions/10249406/powershell-v2-load-a-com-interop-dll which points to a possible problem with mixing 32 dlls in 64 bit PowerShell. As my laptop is 32 and the server 64 bit, I was wondering if this might cause the problem. At least I could pin the line of code where the exception gets thrown: [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

Has anyone an idea?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Reply | Threaded
Open this post in threaded view
|

AW: 64bit problem?

Thiemo.Kellner

I am affraid, the dll file is there. Following code snipped should make sure it is before trying to load the dll

 

      if (-not (Test-Path -Path $log4netDllPathString)) {

            assert-fatal(

                  'I cannot find the logging library at "' +

                  $log4netDllPathString + '"')

            exit 1

      }

#       [void][Reflection.Assembly]::LoadFile('I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll')

      [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

and I actually can see the file with

 

C:\Users\s00489>dir I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll

Volume in drive I is WA-REF$

Volume Serial Number is 2702-33EF

 

Directory of I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release

 

18.11.2013  04:51           301'056 log4net.dll

               1 File(s)        301'056 bytes

               0 Dir(s)  137'992'851'456 bytes free

 

I cannot put the library elsewhere.

 

Maybe there is an issue because it is a network drive but I would not know why it would work on my own laptop then.

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Radovan Raszka [mailto:[hidden email]]
Gesendet: Freitag, 27. Februar 2015 07:54
An: 'Log4NET User'
Betreff: RE: 64bit problem?

 

It looks like powershell can’t find where log4net.dll is located. As log4net is platform neutral (compiled as any CPU), I don’t think 32 x 64 bit OS is issue.

Where you have log4net.dll installed? Probably is good idea to put it into GAC.

Or put it into folder where powershell is installed. Key is to find where powershell tried to find log4net.dll – is it possible to discover this info?

Radovan

 

From: [hidden email] [[hidden email]]
Sent: Thursday, February 26, 2015 4:19 PM
To: [hidden email]
Subject: AW: 64bit problem?

 

Assuming that on either system the most resent framework gets loaded, on both systems 4.0.30319 is used. However, on the server there are both flavours, 32 and 64 bit. I do not know which one is loaded.

 

I forgot to mention that we use log4net 1.2.13, in case this makes a difference. The powershell version on the server is 3, on the laptop it is 4.

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Dominik Psenner [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 15:40
An: 'Log4NET User'
Betreff: AW: 64bit problem?

 

To be honest, the error message is rather cryptic to me. What I know is that log4net is not compiled against a specific architecture. If the targeted .NET framework is installed it should work. Have you checked that?

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:48
An: [hidden email]
Betreff: AW: 64bit problem?

 

I found https://issues.apache.org/jira/browse/LOG4NET-138 . Maybe there is a problem?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:36
An: [hidden email]
Betreff: 64bit problem?

 

Hi all

 

I am at my wits’ end. We developped PowerShell script which uses log4net. I can run the script successfully from a batch file on my laptop but on the server I get

 

Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem'

provider failed.

I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1 :

Exception calling "LoadFile" with "1" argument(s): "The parameter is

incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))"

At line:1 char:1

+ I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1

-stat_activi ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~

    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorExcep

   tion

    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorExceptio

   n,metadata_join_params-thiemo.ps1

 

 

I found http://stackoverflow.com/questions/10249406/powershell-v2-load-a-com-interop-dll which points to a possible problem with mixing 32 dlls in 64 bit PowerShell. As my laptop is 32 and the server 64 bit, I was wondering if this might cause the problem. At least I could pin the line of code where the exception gets thrown: [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

Has anyone an idea?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Reply | Threaded
Open this post in threaded view
|

AW: 64bit problem?

Dominik Psenner

It might be a security issue then.

 

For instance, loading a dll from a network share is (from the operating systems point of view) a dangerous operation. When I try to open a zip file on my computer which is located on a NAS that “lives” outside of the network domain windows requires me to confirm 3 times a error message dialog at me stating “Windows cannot open the folder. The compressed zipped folder is invalid.”, but then it opens up just fine.

 

Yes, windows is like that..

 

Von: [hidden email] [mailto:[hidden email]]
Gesendet: Freitag, 27. Februar 2015 08:42
An: [hidden email]
Betreff: AW: 64bit problem?

 

I am affraid, the dll file is there. Following code snipped should make sure it is before trying to load the dll

 

      if (-not (Test-Path -Path $log4netDllPathString)) {

            assert-fatal(

                  'I cannot find the logging library at "' +

                  $log4netDllPathString + '"')

            exit 1

      }

#       [void][Reflection.Assembly]::LoadFile('I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll')

      [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

and I actually can see the file with

 

C:\Users\s00489>dir I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll

Volume in drive I is WA-REF$

Volume Serial Number is 2702-33EF

 

Directory of I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release

 

18.11.2013  04:51           301'056 log4net.dll

               1 File(s)        301'056 bytes

               0 Dir(s)  137'992'851'456 bytes free

 

I cannot put the library elsewhere.

 

Maybe there is an issue because it is a network drive but I would not know why it would work on my own laptop then.

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Radovan Raszka [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 07:54
An: 'Log4NET User'
Betreff: RE: 64bit problem?

 

It looks like powershell can’t find where log4net.dll is located. As log4net is platform neutral (compiled as any CPU), I don’t think 32 x 64 bit OS is issue.

Where you have log4net.dll installed? Probably is good idea to put it into GAC.

Or put it into folder where powershell is installed. Key is to find where powershell tried to find log4net.dll – is it possible to discover this info?

Radovan

 

From: [hidden email] [[hidden email]]
Sent: Thursday, February 26, 2015 4:19 PM
To: [hidden email]
Subject: AW: 64bit problem?

 

Assuming that on either system the most resent framework gets loaded, on both systems 4.0.30319 is used. However, on the server there are both flavours, 32 and 64 bit. I do not know which one is loaded.

 

I forgot to mention that we use log4net 1.2.13, in case this makes a difference. The powershell version on the server is 3, on the laptop it is 4.

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Dominik Psenner [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 15:40
An: 'Log4NET User'
Betreff: AW: 64bit problem?

 

To be honest, the error message is rather cryptic to me. What I know is that log4net is not compiled against a specific architecture. If the targeted .NET framework is installed it should work. Have you checked that?

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:48
An: [hidden email]
Betreff: AW: 64bit problem?

 

I found https://issues.apache.org/jira/browse/LOG4NET-138 . Maybe there is a problem?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:36
An: [hidden email]
Betreff: 64bit problem?

 

Hi all

 

I am at my wits’ end. We developped PowerShell script which uses log4net. I can run the script successfully from a batch file on my laptop but on the server I get

 

Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem'

provider failed.

I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1 :

Exception calling "LoadFile" with "1" argument(s): "The parameter is

incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))"

At line:1 char:1

+ I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1

-stat_activi ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~

    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorExcep

   tion

    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorExceptio

   n,metadata_join_params-thiemo.ps1

 

 

I found http://stackoverflow.com/questions/10249406/powershell-v2-load-a-com-interop-dll which points to a possible problem with mixing 32 dlls in 64 bit PowerShell. As my laptop is 32 and the server 64 bit, I was wondering if this might cause the problem. At least I could pin the line of code where the exception gets thrown: [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

Has anyone an idea?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Reply | Threaded
Open this post in threaded view
|

AW: 64bit problem?

Thiemo.Kellner

It seem so confusing to me. If there was a security problem loading the modules, I would suspect that my modules where not listed as available with

 

PS I:\wa_analyse\SIS_METASTAT\Files> get-module -listavailable

 

 

    Directory: C:\Windows\system32\WindowsPowerShell\v1.0\Modules

 

 

ModuleType Name                                ExportedCommands

---------- ----                                ----------------

Manifest   ActiveDirectory                     {Get-ADRootDSE, New-ADObject,...

Manifest   ADRMS                               {Update-ADRMS, Uninstall-ADRM...

Manifest   AppLocker                           {Set-AppLockerPolicy, Get-App...

Manifest   BestPractices                       {Get-BpaModel, Invoke-BpaMode...

Manifest   BitsTransfer                        {Add-BitsFile, Remove-BitsTra...

Manifest   CimCmdlets                          {Get-CimAssociatedInstance, G...

Manifest   GroupPolicy                         {Backup-GPO, Copy-GPO, Get-GP...

Script     ISE                                 {New-IseSnippet, Import-IseSn...

Manifest   Microsoft.PowerShell.Diagnostics    {Get-WinEvent, Get-Counter, I...

Manifest   Microsoft.PowerShell.Host           {Start-Transcript, Stop-Trans...

Manifest   Microsoft.PowerShell.Management     {Add-Content, Clear-Content, ...

Manifest   Microsoft.PowerShell.Security       {Get-Acl, Set-Acl, Get-PfxCer...

Manifest   Microsoft.PowerShell.Utility        {Format-List, Format-Custom, ...

Manifest   Microsoft.WSMan.Management          {Disable-WSManCredSSP, Enable...

Script     PSDiagnostics                       {Disable-PSTrace, Disable-PSW...

Binary     PSScheduledJob                      {New-JobTrigger, Add-JobTrigg...

Manifest   PSWorkflow                          {New-PSWorkflowExecutionOptio...

Manifest   PSWorkflowUtility                   Invoke-AsWorkflow

Manifest   ServerManager                       {Get-WindowsFeature, Add-Wind...

Manifest   TroubleshootingPack                 {Get-TroubleshootingPack, Inv...

 

 

    Directory: C:\Program Files\Microsoft Monitoring Agent\Agent\PowerShell

 

 

ModuleType Name                                ExportedCommands

---------- ----                                ----------------

Binary     Microsoft.MonitoringAgent.PowerS... {Checkpoint-WebApplicationMon...

 

 

    Directory: I:\WA_ANALYSE\AAA_INFA_CORE\Libs

 

 

ModuleType Name                                ExportedCommands

---------- ----                                ----------------

Script     BFS.Powershell.Logging              {assert-debug, assert-error, ...

Script     BFS.Powershell.PowerCenter          {approve-pocallworkflows, app...

Script     BFS.Powershell.Utility              {get-basename, get-dirname, g...

 

The availability on the workstation looks the same…

 

Ok, I found a book that states that binary modules, i.e. dll, usually cannot be loaded from network drives for security reasons. But now if it *usually* is not allowed how can I get the exception? I can see that the modules can get loaded because they are not binary. It is, however, not investigated if the happen to load binary modules themselves dynamically.

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Dominik Psenner [mailto:[hidden email]]
Gesendet: Freitag, 27. Februar 2015 09:48
An: 'Log4NET User'
Betreff: AW: 64bit problem?

 

It might be a security issue then.

 

For instance, loading a dll from a network share is (from the operating systems point of view) a dangerous operation. When I try to open a zip file on my computer which is located on a NAS that “lives” outside of the network domain windows requires me to confirm 3 times a error message dialog at me stating “Windows cannot open the folder. The compressed zipped folder is invalid.”, but then it opens up just fine.

 

Yes, windows is like that..

 

Von: [hidden email] [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 08:42
An: [hidden email]
Betreff: AW: 64bit problem?

 

I am affraid, the dll file is there. Following code snipped should make sure it is before trying to load the dll

 

      if (-not (Test-Path -Path $log4netDllPathString)) {

            assert-fatal(

                  'I cannot find the logging library at "' +

                  $log4netDllPathString + '"')

            exit 1

      }

#       [void][Reflection.Assembly]::LoadFile('I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll')

      [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

and I actually can see the file with

 

C:\Users\s00489>dir I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll

Volume in drive I is WA-REF$

Volume Serial Number is 2702-33EF

 

Directory of I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release

 

18.11.2013  04:51           301'056 log4net.dll

               1 File(s)        301'056 bytes

               0 Dir(s)  137'992'851'456 bytes free

 

I cannot put the library elsewhere.

 

Maybe there is an issue because it is a network drive but I would not know why it would work on my own laptop then.

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Radovan Raszka [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 07:54
An: 'Log4NET User'
Betreff: RE: 64bit problem?

 

It looks like powershell can’t find where log4net.dll is located. As log4net is platform neutral (compiled as any CPU), I don’t think 32 x 64 bit OS is issue.

Where you have log4net.dll installed? Probably is good idea to put it into GAC.

Or put it into folder where powershell is installed. Key is to find where powershell tried to find log4net.dll – is it possible to discover this info?

Radovan

 

From: [hidden email] [[hidden email]]
Sent: Thursday, February 26, 2015 4:19 PM
To: [hidden email]
Subject: AW: 64bit problem?

 

Assuming that on either system the most resent framework gets loaded, on both systems 4.0.30319 is used. However, on the server there are both flavours, 32 and 64 bit. I do not know which one is loaded.

 

I forgot to mention that we use log4net 1.2.13, in case this makes a difference. The powershell version on the server is 3, on the laptop it is 4.

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Dominik Psenner [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 15:40
An: 'Log4NET User'
Betreff: AW: 64bit problem?

 

To be honest, the error message is rather cryptic to me. What I know is that log4net is not compiled against a specific architecture. If the targeted .NET framework is installed it should work. Have you checked that?

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:48
An: [hidden email]
Betreff: AW: 64bit problem?

 

I found https://issues.apache.org/jira/browse/LOG4NET-138 . Maybe there is a problem?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:36
An: [hidden email]
Betreff: 64bit problem?

 

Hi all

 

I am at my wits’ end. We developped PowerShell script which uses log4net. I can run the script successfully from a batch file on my laptop but on the server I get

 

Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem'

provider failed.

I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1 :

Exception calling "LoadFile" with "1" argument(s): "The parameter is

incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))"

At line:1 char:1

+ I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1

-stat_activi ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~

    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorExcep

   tion

    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorExceptio

   n,metadata_join_params-thiemo.ps1

 

 

I found http://stackoverflow.com/questions/10249406/powershell-v2-load-a-com-interop-dll which points to a possible problem with mixing 32 dlls in 64 bit PowerShell. As my laptop is 32 and the server 64 bit, I was wondering if this might cause the problem. At least I could pin the line of code where the exception gets thrown: [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

Has anyone an idea?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Reply | Threaded
Open this post in threaded view
|

AW: 64bit problem?

Dominik Psenner

You could leverage this security vulnerabilities mayhem if you’d copy the dll to a local temp folder, load it, execute it, unload it when all the work is done and finally remove the temporary file.. J

 

Von: [hidden email] [mailto:[hidden email]]
Gesendet: Freitag, 27. Februar 2015 13:54
An: [hidden email]
Betreff: AW: 64bit problem?

 

It seem so confusing to me. If there was a security problem loading the modules, I would suspect that my modules where not listed as available with

 

PS I:\wa_analyse\SIS_METASTAT\Files> get-module -listavailable

 

 

    Directory: C:\Windows\system32\WindowsPowerShell\v1.0\Modules

 

 

ModuleType Name                                ExportedCommands

---------- ----                                ----------------

Manifest   ActiveDirectory                     {Get-ADRootDSE, New-ADObject,...

Manifest   ADRMS                               {Update-ADRMS, Uninstall-ADRM...

Manifest   AppLocker                           {Set-AppLockerPolicy, Get-App...

Manifest   BestPractices                       {Get-BpaModel, Invoke-BpaMode...

Manifest   BitsTransfer                        {Add-BitsFile, Remove-BitsTra...

Manifest   CimCmdlets                          {Get-CimAssociatedInstance, G...

Manifest   GroupPolicy                         {Backup-GPO, Copy-GPO, Get-GP...

Script     ISE                                 {New-IseSnippet, Import-IseSn...

Manifest   Microsoft.PowerShell.Diagnostics    {Get-WinEvent, Get-Counter, I...

Manifest   Microsoft.PowerShell.Host           {Start-Transcript, Stop-Trans...

Manifest   Microsoft.PowerShell.Management     {Add-Content, Clear-Content, ...

Manifest   Microsoft.PowerShell.Security       {Get-Acl, Set-Acl, Get-PfxCer...

Manifest   Microsoft.PowerShell.Utility        {Format-List, Format-Custom, ...

Manifest   Microsoft.WSMan.Management          {Disable-WSManCredSSP, Enable...

Script     PSDiagnostics                       {Disable-PSTrace, Disable-PSW...

Binary     PSScheduledJob                      {New-JobTrigger, Add-JobTrigg...

Manifest   PSWorkflow                          {New-PSWorkflowExecutionOptio...

Manifest   PSWorkflowUtility                   Invoke-AsWorkflow

Manifest   ServerManager                       {Get-WindowsFeature, Add-Wind...

Manifest   TroubleshootingPack                 {Get-TroubleshootingPack, Inv...

 

 

    Directory: C:\Program Files\Microsoft Monitoring Agent\Agent\PowerShell

 

 

ModuleType Name                                ExportedCommands

---------- ----                                ----------------

Binary     Microsoft.MonitoringAgent.PowerS... {Checkpoint-WebApplicationMon...

 

 

    Directory: I:\WA_ANALYSE\AAA_INFA_CORE\Libs

 

 

ModuleType Name                                ExportedCommands

---------- ----                                ----------------

Script     BFS.Powershell.Logging              {assert-debug, assert-error, ...

Script     BFS.Powershell.PowerCenter          {approve-pocallworkflows, app...

Script     BFS.Powershell.Utility              {get-basename, get-dirname, g...

 

The availability on the workstation looks the same…

 

Ok, I found a book that states that binary modules, i.e. dll, usually cannot be loaded from network drives for security reasons. But now if it *usually* is not allowed how can I get the exception? I can see that the modules can get loaded because they are not binary. It is, however, not investigated if the happen to load binary modules themselves dynamically.

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Dominik Psenner [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 09:48
An: 'Log4NET User'
Betreff: AW: 64bit problem?

 

It might be a security issue then.

 

For instance, loading a dll from a network share is (from the operating systems point of view) a dangerous operation. When I try to open a zip file on my computer which is located on a NAS that “lives” outside of the network domain windows requires me to confirm 3 times a error message dialog at me stating “Windows cannot open the folder. The compressed zipped folder is invalid.”, but then it opens up just fine.

 

Yes, windows is like that..

 

Von: [hidden email] [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 08:42
An: [hidden email]
Betreff: AW: 64bit problem?

 

I am affraid, the dll file is there. Following code snipped should make sure it is before trying to load the dll

 

      if (-not (Test-Path -Path $log4netDllPathString)) {

            assert-fatal(

                  'I cannot find the logging library at "' +

                  $log4netDllPathString + '"')

            exit 1

      }

#       [void][Reflection.Assembly]::LoadFile('I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll')

      [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

and I actually can see the file with

 

C:\Users\s00489>dir I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll

Volume in drive I is WA-REF$

Volume Serial Number is 2702-33EF

 

Directory of I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release

 

18.11.2013  04:51           301'056 log4net.dll

               1 File(s)        301'056 bytes

               0 Dir(s)  137'992'851'456 bytes free

 

I cannot put the library elsewhere.

 

Maybe there is an issue because it is a network drive but I would not know why it would work on my own laptop then.

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Radovan Raszka [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 07:54
An: 'Log4NET User'
Betreff: RE: 64bit problem?

 

It looks like powershell can’t find where log4net.dll is located. As log4net is platform neutral (compiled as any CPU), I don’t think 32 x 64 bit OS is issue.

Where you have log4net.dll installed? Probably is good idea to put it into GAC.

Or put it into folder where powershell is installed. Key is to find where powershell tried to find log4net.dll – is it possible to discover this info?

Radovan

 

From: [hidden email] [[hidden email]]
Sent: Thursday, February 26, 2015 4:19 PM
To: [hidden email]
Subject: AW: 64bit problem?

 

Assuming that on either system the most resent framework gets loaded, on both systems 4.0.30319 is used. However, on the server there are both flavours, 32 and 64 bit. I do not know which one is loaded.

 

I forgot to mention that we use log4net 1.2.13, in case this makes a difference. The powershell version on the server is 3, on the laptop it is 4.

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Dominik Psenner [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 15:40
An: 'Log4NET User'
Betreff: AW: 64bit problem?

 

To be honest, the error message is rather cryptic to me. What I know is that log4net is not compiled against a specific architecture. If the targeted .NET framework is installed it should work. Have you checked that?

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:48
An: [hidden email]
Betreff: AW: 64bit problem?

 

I found https://issues.apache.org/jira/browse/LOG4NET-138 . Maybe there is a problem?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:36
An: [hidden email]
Betreff: 64bit problem?

 

Hi all

 

I am at my wits’ end. We developped PowerShell script which uses log4net. I can run the script successfully from a batch file on my laptop but on the server I get

 

Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem'

provider failed.

I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1 :

Exception calling "LoadFile" with "1" argument(s): "The parameter is

incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))"

At line:1 char:1

+ I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1

-stat_activi ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~

    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorExcep

   tion

    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorExceptio

   n,metadata_join_params-thiemo.ps1

 

 

I found http://stackoverflow.com/questions/10249406/powershell-v2-load-a-com-interop-dll which points to a possible problem with mixing 32 dlls in 64 bit PowerShell. As my laptop is 32 and the server 64 bit, I was wondering if this might cause the problem. At least I could pin the line of code where the exception gets thrown: [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

Has anyone an idea?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Reply | Threaded
Open this post in threaded view
|

AW: 64bit problem?

Thiemo.Kellner

I could indeed… urgs.

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Dominik Psenner [mailto:[hidden email]]
Gesendet: Freitag, 27. Februar 2015 14:13
An: 'Log4NET User'
Betreff: AW: 64bit problem?

 

You could leverage this security vulnerabilities mayhem if you’d copy the dll to a local temp folder, load it, execute it, unload it when all the work is done and finally remove the temporary file.. J

 

Von: [hidden email] [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 13:54
An: [hidden email]
Betreff: AW: 64bit problem?

 

It seem so confusing to me. If there was a security problem loading the modules, I would suspect that my modules where not listed as available with

 

PS I:\wa_analyse\SIS_METASTAT\Files> get-module -listavailable

 

 

    Directory: C:\Windows\system32\WindowsPowerShell\v1.0\Modules

 

 

ModuleType Name                                ExportedCommands

---------- ----                                ----------------

Manifest   ActiveDirectory                     {Get-ADRootDSE, New-ADObject,...

Manifest   ADRMS                               {Update-ADRMS, Uninstall-ADRM...

Manifest   AppLocker                           {Set-AppLockerPolicy, Get-App...

Manifest   BestPractices                       {Get-BpaModel, Invoke-BpaMode...

Manifest   BitsTransfer                        {Add-BitsFile, Remove-BitsTra...

Manifest   CimCmdlets                          {Get-CimAssociatedInstance, G...

Manifest   GroupPolicy                         {Backup-GPO, Copy-GPO, Get-GP...

Script     ISE                                 {New-IseSnippet, Import-IseSn...

Manifest   Microsoft.PowerShell.Diagnostics    {Get-WinEvent, Get-Counter, I...

Manifest   Microsoft.PowerShell.Host           {Start-Transcript, Stop-Trans...

Manifest   Microsoft.PowerShell.Management     {Add-Content, Clear-Content, ...

Manifest   Microsoft.PowerShell.Security       {Get-Acl, Set-Acl, Get-PfxCer...

Manifest   Microsoft.PowerShell.Utility        {Format-List, Format-Custom, ...

Manifest   Microsoft.WSMan.Management          {Disable-WSManCredSSP, Enable...

Script     PSDiagnostics                       {Disable-PSTrace, Disable-PSW...

Binary     PSScheduledJob                      {New-JobTrigger, Add-JobTrigg...

Manifest   PSWorkflow                          {New-PSWorkflowExecutionOptio...

Manifest   PSWorkflowUtility                   Invoke-AsWorkflow

Manifest   ServerManager                       {Get-WindowsFeature, Add-Wind...

Manifest   TroubleshootingPack                 {Get-TroubleshootingPack, Inv...

 

 

    Directory: C:\Program Files\Microsoft Monitoring Agent\Agent\PowerShell

 

 

ModuleType Name                                ExportedCommands

---------- ----                                ----------------

Binary     Microsoft.MonitoringAgent.PowerS... {Checkpoint-WebApplicationMon...

 

 

    Directory: I:\WA_ANALYSE\AAA_INFA_CORE\Libs

 

 

ModuleType Name                                ExportedCommands

---------- ----                                ----------------

Script     BFS.Powershell.Logging              {assert-debug, assert-error, ...

Script     BFS.Powershell.PowerCenter          {approve-pocallworkflows, app...

Script     BFS.Powershell.Utility              {get-basename, get-dirname, g...

 

The availability on the workstation looks the same…

 

Ok, I found a book that states that binary modules, i.e. dll, usually cannot be loaded from network drives for security reasons. But now if it *usually* is not allowed how can I get the exception? I can see that the modules can get loaded because they are not binary. It is, however, not investigated if the happen to load binary modules themselves dynamically.

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Dominik Psenner [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 09:48
An: 'Log4NET User'
Betreff: AW: 64bit problem?

 

It might be a security issue then.

 

For instance, loading a dll from a network share is (from the operating systems point of view) a dangerous operation. When I try to open a zip file on my computer which is located on a NAS that “lives” outside of the network domain windows requires me to confirm 3 times a error message dialog at me stating “Windows cannot open the folder. The compressed zipped folder is invalid.”, but then it opens up just fine.

 

Yes, windows is like that..

 

Von: [hidden email] [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 08:42
An: [hidden email]
Betreff: AW: 64bit problem?

 

I am affraid, the dll file is there. Following code snipped should make sure it is before trying to load the dll

 

      if (-not (Test-Path -Path $log4netDllPathString)) {

            assert-fatal(

                  'I cannot find the logging library at "' +

                  $log4netDllPathString + '"')

            exit 1

      }

#       [void][Reflection.Assembly]::LoadFile('I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll')

      [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

and I actually can see the file with

 

C:\Users\s00489>dir I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll

Volume in drive I is WA-REF$

Volume Serial Number is 2702-33EF

 

Directory of I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release

 

18.11.2013  04:51           301'056 log4net.dll

               1 File(s)        301'056 bytes

               0 Dir(s)  137'992'851'456 bytes free

 

I cannot put the library elsewhere.

 

Maybe there is an issue because it is a network drive but I would not know why it would work on my own laptop then.

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Radovan Raszka [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 07:54
An: 'Log4NET User'
Betreff: RE: 64bit problem?

 

It looks like powershell can’t find where log4net.dll is located. As log4net is platform neutral (compiled as any CPU), I don’t think 32 x 64 bit OS is issue.

Where you have log4net.dll installed? Probably is good idea to put it into GAC.

Or put it into folder where powershell is installed. Key is to find where powershell tried to find log4net.dll – is it possible to discover this info?

Radovan

 

From: [hidden email] [[hidden email]]
Sent: Thursday, February 26, 2015 4:19 PM
To: [hidden email]
Subject: AW: 64bit problem?

 

Assuming that on either system the most resent framework gets loaded, on both systems 4.0.30319 is used. However, on the server there are both flavours, 32 and 64 bit. I do not know which one is loaded.

 

I forgot to mention that we use log4net 1.2.13, in case this makes a difference. The powershell version on the server is 3, on the laptop it is 4.

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Dominik Psenner [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 15:40
An: 'Log4NET User'
Betreff: AW: 64bit problem?

 

To be honest, the error message is rather cryptic to me. What I know is that log4net is not compiled against a specific architecture. If the targeted .NET framework is installed it should work. Have you checked that?

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:48
An: [hidden email]
Betreff: AW: 64bit problem?

 

I found https://issues.apache.org/jira/browse/LOG4NET-138 . Maybe there is a problem?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:36
An: [hidden email]
Betreff: 64bit problem?

 

Hi all

 

I am at my wits’ end. We developped PowerShell script which uses log4net. I can run the script successfully from a batch file on my laptop but on the server I get

 

Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem'

provider failed.

I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1 :

Exception calling "LoadFile" with "1" argument(s): "The parameter is

incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))"

At line:1 char:1

+ I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1

-stat_activi ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~

    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorExcep

   tion

    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorExceptio

   n,metadata_join_params-thiemo.ps1

 

 

I found http://stackoverflow.com/questions/10249406/powershell-v2-load-a-com-interop-dll which points to a possible problem with mixing 32 dlls in 64 bit PowerShell. As my laptop is 32 and the server 64 bit, I was wondering if this might cause the problem. At least I could pin the line of code where the exception gets thrown: [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

Has anyone an idea?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Reply | Threaded
Open this post in threaded view
|

AW: 64bit problem?

Dominik Psenner

Let us know if that resolved your issue. It might be a handy reference to future readers.

 

Von: [hidden email] [mailto:[hidden email]]
Gesendet: Freitag, 27. Februar 2015 14:15
An: [hidden email]
Betreff: AW: 64bit problem?

 

I could indeed… urgs.

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Dominik Psenner [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 14:13
An: 'Log4NET User'
Betreff: AW: 64bit problem?

 

You could leverage this security vulnerabilities mayhem if you’d copy the dll to a local temp folder, load it, execute it, unload it when all the work is done and finally remove the temporary file.. J

 

Von: [hidden email] [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 13:54
An: [hidden email]
Betreff: AW: 64bit problem?

 

It seem so confusing to me. If there was a security problem loading the modules, I would suspect that my modules where not listed as available with

 

PS I:\wa_analyse\SIS_METASTAT\Files> get-module -listavailable

 

 

    Directory: C:\Windows\system32\WindowsPowerShell\v1.0\Modules

 

 

ModuleType Name                                ExportedCommands

---------- ----                                ----------------

Manifest   ActiveDirectory                     {Get-ADRootDSE, New-ADObject,...

Manifest   ADRMS                               {Update-ADRMS, Uninstall-ADRM...

Manifest   AppLocker                           {Set-AppLockerPolicy, Get-App...

Manifest   BestPractices                       {Get-BpaModel, Invoke-BpaMode...

Manifest   BitsTransfer                        {Add-BitsFile, Remove-BitsTra...

Manifest   CimCmdlets                          {Get-CimAssociatedInstance, G...

Manifest   GroupPolicy                         {Backup-GPO, Copy-GPO, Get-GP...

Script     ISE                                 {New-IseSnippet, Import-IseSn...

Manifest   Microsoft.PowerShell.Diagnostics    {Get-WinEvent, Get-Counter, I...

Manifest   Microsoft.PowerShell.Host           {Start-Transcript, Stop-Trans...

Manifest   Microsoft.PowerShell.Management     {Add-Content, Clear-Content, ...

Manifest   Microsoft.PowerShell.Security       {Get-Acl, Set-Acl, Get-PfxCer...

Manifest   Microsoft.PowerShell.Utility        {Format-List, Format-Custom, ...

Manifest   Microsoft.WSMan.Management          {Disable-WSManCredSSP, Enable...

Script     PSDiagnostics                       {Disable-PSTrace, Disable-PSW...

Binary     PSScheduledJob                      {New-JobTrigger, Add-JobTrigg...

Manifest   PSWorkflow                          {New-PSWorkflowExecutionOptio...

Manifest   PSWorkflowUtility                   Invoke-AsWorkflow

Manifest   ServerManager                       {Get-WindowsFeature, Add-Wind...

Manifest   TroubleshootingPack                 {Get-TroubleshootingPack, Inv...

 

 

    Directory: C:\Program Files\Microsoft Monitoring Agent\Agent\PowerShell

 

 

ModuleType Name                                ExportedCommands

---------- ----                                ----------------

Binary     Microsoft.MonitoringAgent.PowerS... {Checkpoint-WebApplicationMon...

 

 

    Directory: I:\WA_ANALYSE\AAA_INFA_CORE\Libs

 

 

ModuleType Name                                ExportedCommands

---------- ----                                ----------------

Script     BFS.Powershell.Logging              {assert-debug, assert-error, ...

Script     BFS.Powershell.PowerCenter          {approve-pocallworkflows, app...

Script     BFS.Powershell.Utility              {get-basename, get-dirname, g...

 

The availability on the workstation looks the same…

 

Ok, I found a book that states that binary modules, i.e. dll, usually cannot be loaded from network drives for security reasons. But now if it *usually* is not allowed how can I get the exception? I can see that the modules can get loaded because they are not binary. It is, however, not investigated if the happen to load binary modules themselves dynamically.

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Dominik Psenner [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 09:48
An: 'Log4NET User'
Betreff: AW: 64bit problem?

 

It might be a security issue then.

 

For instance, loading a dll from a network share is (from the operating systems point of view) a dangerous operation. When I try to open a zip file on my computer which is located on a NAS that “lives” outside of the network domain windows requires me to confirm 3 times a error message dialog at me stating “Windows cannot open the folder. The compressed zipped folder is invalid.”, but then it opens up just fine.

 

Yes, windows is like that..

 

Von: [hidden email] [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 08:42
An: [hidden email]
Betreff: AW: 64bit problem?

 

I am affraid, the dll file is there. Following code snipped should make sure it is before trying to load the dll

 

      if (-not (Test-Path -Path $log4netDllPathString)) {

            assert-fatal(

                  'I cannot find the logging library at "' +

                  $log4netDllPathString + '"')

            exit 1

      }

#       [void][Reflection.Assembly]::LoadFile('I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll')

      [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

and I actually can see the file with

 

C:\Users\s00489>dir I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll

Volume in drive I is WA-REF$

Volume Serial Number is 2702-33EF

 

Directory of I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release

 

18.11.2013  04:51           301'056 log4net.dll

               1 File(s)        301'056 bytes

               0 Dir(s)  137'992'851'456 bytes free

 

I cannot put the library elsewhere.

 

Maybe there is an issue because it is a network drive but I would not know why it would work on my own laptop then.

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Radovan Raszka [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 07:54
An: 'Log4NET User'
Betreff: RE: 64bit problem?

 

It looks like powershell can’t find where log4net.dll is located. As log4net is platform neutral (compiled as any CPU), I don’t think 32 x 64 bit OS is issue.

Where you have log4net.dll installed? Probably is good idea to put it into GAC.

Or put it into folder where powershell is installed. Key is to find where powershell tried to find log4net.dll – is it possible to discover this info?

Radovan

 

From: [hidden email] [[hidden email]]
Sent: Thursday, February 26, 2015 4:19 PM
To: [hidden email]
Subject: AW: 64bit problem?

 

Assuming that on either system the most resent framework gets loaded, on both systems 4.0.30319 is used. However, on the server there are both flavours, 32 and 64 bit. I do not know which one is loaded.

 

I forgot to mention that we use log4net 1.2.13, in case this makes a difference. The powershell version on the server is 3, on the laptop it is 4.

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Dominik Psenner [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 15:40
An: 'Log4NET User'
Betreff: AW: 64bit problem?

 

To be honest, the error message is rather cryptic to me. What I know is that log4net is not compiled against a specific architecture. If the targeted .NET framework is installed it should work. Have you checked that?

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:48
An: [hidden email]
Betreff: AW: 64bit problem?

 

I found https://issues.apache.org/jira/browse/LOG4NET-138 . Maybe there is a problem?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:36
An: [hidden email]
Betreff: 64bit problem?

 

Hi all

 

I am at my wits’ end. We developped PowerShell script which uses log4net. I can run the script successfully from a batch file on my laptop but on the server I get

 

Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem'

provider failed.

I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1 :

Exception calling "LoadFile" with "1" argument(s): "The parameter is

incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))"

At line:1 char:1

+ I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1

-stat_activi ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~

    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorExcep

   tion

    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorExceptio

   n,metadata_join_params-thiemo.ps1

 

 

I found http://stackoverflow.com/questions/10249406/powershell-v2-load-a-com-interop-dll which points to a possible problem with mixing 32 dlls in 64 bit PowerShell. As my laptop is 32 and the server 64 bit, I was wondering if this might cause the problem. At least I could pin the line of code where the exception gets thrown: [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

Has anyone an idea?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Reply | Threaded
Open this post in threaded view
|

RE: 64bit problem?

Anthony Francisco
In reply to this post by Dominik Psenner

Older versions of .NET made it hard to load assemblies from the network. It’s much easier with .NET 4 and up by using the <loadFromRemoveSources> configuration element.

 

See https://msdn.microsoft.com/en-us/library/dd409252(v=vs.110).aspx

See also: http://weblog.west-wind.com/posts/2011/Mar/22/Loading-Assemblies-off-Network-Drives

 

So what this means is that you’ll need to update your powershell configuration file. It sounds like you might not have privileges to do that considering that you don’t have privileges to put log4net and other assemblies on the local machine.

 

-          Ants

 

From: Dominik Psenner [mailto:[hidden email]]
Sent: Friday, 27 February, 2015 03:48
To: 'Log4NET User'
Subject: AW: 64bit problem?

 

It might be a security issue then.

 

For instance, loading a dll from a network share is (from the operating systems point of view) a dangerous operation. When I try to open a zip file on my computer which is located on a NAS that “lives” outside of the network domain windows requires me to confirm 3 times a error message dialog at me stating “Windows cannot open the folder. The compressed zipped folder is invalid.”, but then it opens up just fine.

 

Yes, windows is like that..

 

Von: [hidden email] [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 08:42
An: [hidden email]
Betreff: AW: 64bit problem?

 

I am affraid, the dll file is there. Following code snipped should make sure it is before trying to load the dll

 

      if (-not (Test-Path -Path $log4netDllPathString)) {

            assert-fatal(

                  'I cannot find the logging library at "' +

                  $log4netDllPathString + '"')

            exit 1

      }

#       [void][Reflection.Assembly]::LoadFile('I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll')

      [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

and I actually can see the file with

 

C:\Users\s00489>dir I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll

Volume in drive I is WA-REF$

Volume Serial Number is 2702-33EF

 

Directory of I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release

 

18.11.2013  04:51           301'056 log4net.dll

               1 File(s)        301'056 bytes

               0 Dir(s)  137'992'851'456 bytes free

 

I cannot put the library elsewhere.

 

Maybe there is an issue because it is a network drive but I would not know why it would work on my own laptop then.

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Radovan Raszka [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 07:54
An: 'Log4NET User'
Betreff: RE: 64bit problem?

 

It looks like powershell can’t find where log4net.dll is located. As log4net is platform neutral (compiled as any CPU), I don’t think 32 x 64 bit OS is issue.

Where you have log4net.dll installed? Probably is good idea to put it into GAC.

Or put it into folder where powershell is installed. Key is to find where powershell tried to find log4net.dll – is it possible to discover this info?

Radovan

 

From: [hidden email] [[hidden email]]
Sent: Thursday, February 26, 2015 4:19 PM
To: [hidden email]
Subject: AW: 64bit problem?

 

Assuming that on either system the most resent framework gets loaded, on both systems 4.0.30319 is used. However, on the server there are both flavours, 32 and 64 bit. I do not know which one is loaded.

 

I forgot to mention that we use log4net 1.2.13, in case this makes a difference. The powershell version on the server is 3, on the laptop it is 4.

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Dominik Psenner [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 15:40
An: 'Log4NET User'
Betreff: AW: 64bit problem?

 

To be honest, the error message is rather cryptic to me. What I know is that log4net is not compiled against a specific architecture. If the targeted .NET framework is installed it should work. Have you checked that?

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:48
An: [hidden email]
Betreff: AW: 64bit problem?

 

I found https://issues.apache.org/jira/browse/LOG4NET-138 . Maybe there is a problem?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:36
An: [hidden email]
Betreff: 64bit problem?

 

Hi all

 

I am at my wits’ end. We developped PowerShell script which uses log4net. I can run the script successfully from a batch file on my laptop but on the server I get

 

Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem'

provider failed.

I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1 :

Exception calling "LoadFile" with "1" argument(s): "The parameter is

incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))"

At line:1 char:1

+ I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1

-stat_activi ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~

    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorExcep

   tion

    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorExceptio

   n,metadata_join_params-thiemo.ps1

 

 

I found http://stackoverflow.com/questions/10249406/powershell-v2-load-a-com-interop-dll which points to a possible problem with mixing 32 dlls in 64 bit PowerShell. As my laptop is 32 and the server 64 bit, I was wondering if this might cause the problem. At least I could pin the line of code where the exception gets thrown: [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

Has anyone an idea?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Reply | Threaded
Open this post in threaded view
|

AW: 64bit problem?

Thiemo.Kellner

Thanks for the hint. I also found this configuration at http://stackoverflow.com/questions/19957161/add-type-load-assembly-from-network-unc-share-error-0x80131515

 

However, I would prefer not to change the PowerShell behavior in general. I’d rather to tweak a runtime setup. I am still investigation on that. I will let you know the outcome.

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Anthony Francisco [mailto:[hidden email]]
Gesendet: Freitag, 27. Februar 2015 14:40
An: 'Log4NET User'
Betreff: RE: 64bit problem?

 

Older versions of .NET made it hard to load assemblies from the network. It’s much easier with .NET 4 and up by using the <loadFromRemoveSources> configuration element.

 

See https://msdn.microsoft.com/en-us/library/dd409252(v=vs.110).aspx

See also: http://weblog.west-wind.com/posts/2011/Mar/22/Loading-Assemblies-off-Network-Drives

 

So what this means is that you’ll need to update your powershell configuration file. It sounds like you might not have privileges to do that considering that you don’t have privileges to put log4net and other assemblies on the local machine.

 

-          Ants

 

From: Dominik Psenner [[hidden email]]
Sent: Friday, 27 February, 2015 03:48
To: 'Log4NET User'
Subject: AW: 64bit problem?

 

It might be a security issue then.

 

For instance, loading a dll from a network share is (from the operating systems point of view) a dangerous operation. When I try to open a zip file on my computer which is located on a NAS that “lives” outside of the network domain windows requires me to confirm 3 times a error message dialog at me stating “Windows cannot open the folder. The compressed zipped folder is invalid.”, but then it opens up just fine.

 

Yes, windows is like that..

 

Von: [hidden email] [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 08:42
An: [hidden email]
Betreff: AW: 64bit problem?

 

I am affraid, the dll file is there. Following code snipped should make sure it is before trying to load the dll

 

      if (-not (Test-Path -Path $log4netDllPathString)) {

            assert-fatal(

                  'I cannot find the logging library at "' +

                  $log4netDllPathString + '"')

            exit 1

      }

#       [void][Reflection.Assembly]::LoadFile('I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll')

      [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

and I actually can see the file with

 

C:\Users\s00489>dir I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll

Volume in drive I is WA-REF$

Volume Serial Number is 2702-33EF

 

Directory of I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release

 

18.11.2013  04:51           301'056 log4net.dll

               1 File(s)        301'056 bytes

               0 Dir(s)  137'992'851'456 bytes free

 

I cannot put the library elsewhere.

 

Maybe there is an issue because it is a network drive but I would not know why it would work on my own laptop then.

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Radovan Raszka [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 07:54
An: 'Log4NET User'
Betreff: RE: 64bit problem?

 

It looks like powershell can’t find where log4net.dll is located. As log4net is platform neutral (compiled as any CPU), I don’t think 32 x 64 bit OS is issue.

Where you have log4net.dll installed? Probably is good idea to put it into GAC.

Or put it into folder where powershell is installed. Key is to find where powershell tried to find log4net.dll – is it possible to discover this info?

Radovan

 

From: [hidden email] [[hidden email]]
Sent: Thursday, February 26, 2015 4:19 PM
To: [hidden email]
Subject: AW: 64bit problem?

 

Assuming that on either system the most resent framework gets loaded, on both systems 4.0.30319 is used. However, on the server there are both flavours, 32 and 64 bit. I do not know which one is loaded.

 

I forgot to mention that we use log4net 1.2.13, in case this makes a difference. The powershell version on the server is 3, on the laptop it is 4.

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Dominik Psenner [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 15:40
An: 'Log4NET User'
Betreff: AW: 64bit problem?

 

To be honest, the error message is rather cryptic to me. What I know is that log4net is not compiled against a specific architecture. If the targeted .NET framework is installed it should work. Have you checked that?

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:48
An: [hidden email]
Betreff: AW: 64bit problem?

 

I found https://issues.apache.org/jira/browse/LOG4NET-138 . Maybe there is a problem?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:36
An: [hidden email]
Betreff: 64bit problem?

 

Hi all

 

I am at my wits’ end. We developped PowerShell script which uses log4net. I can run the script successfully from a batch file on my laptop but on the server I get

 

Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem'

provider failed.

I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1 :

Exception calling "LoadFile" with "1" argument(s): "The parameter is

incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))"

At line:1 char:1

+ I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1

-stat_activi ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~

    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorExcep

   tion

    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorExceptio

   n,metadata_join_params-thiemo.ps1

 

 

I found http://stackoverflow.com/questions/10249406/powershell-v2-load-a-com-interop-dll which points to a possible problem with mixing 32 dlls in 64 bit PowerShell. As my laptop is 32 and the server 64 bit, I was wondering if this might cause the problem. At least I could pin the line of code where the exception gets thrown: [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

Has anyone an idea?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Reply | Threaded
Open this post in threaded view
|

AW: 64bit problem?

Thiemo.Kellner

YAHOOOO!

 

Thanks to all so kind to nudge me to the right solution. It was a security issue after all NOT a architecture problem. I tried to load the dll on the network by [void][Reflection.Assembly]::LoadFile($log4netDllPathString) .  I did not try to re-configure PowerShell execution by global config file. But I did change the load call to [void][Reflection.Assembly]:: UnsafeLoadFrom($log4netDllPathString)

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: [hidden email] [mailto:[hidden email]]
Gesendet: Freitag, 27. Februar 2015 14:45
An: [hidden email]
Betreff: AW: 64bit problem?

 

Thanks for the hint. I also found this configuration at http://stackoverflow.com/questions/19957161/add-type-load-assembly-from-network-unc-share-error-0x80131515

 

However, I would prefer not to change the PowerShell behavior in general. I’d rather to tweak a runtime setup. I am still investigation on that. I will let you know the outcome.

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Anthony Francisco [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 14:40
An: 'Log4NET User'
Betreff: RE: 64bit problem?

 

Older versions of .NET made it hard to load assemblies from the network. It’s much easier with .NET 4 and up by using the <loadFromRemoveSources> configuration element.

 

See https://msdn.microsoft.com/en-us/library/dd409252(v=vs.110).aspx

See also: http://weblog.west-wind.com/posts/2011/Mar/22/Loading-Assemblies-off-Network-Drives

 

So what this means is that you’ll need to update your powershell configuration file. It sounds like you might not have privileges to do that considering that you don’t have privileges to put log4net and other assemblies on the local machine.

 

-          Ants

 

From: Dominik Psenner [[hidden email]]
Sent: Friday, 27 February, 2015 03:48
To: 'Log4NET User'
Subject: AW: 64bit problem?

 

It might be a security issue then.

 

For instance, loading a dll from a network share is (from the operating systems point of view) a dangerous operation. When I try to open a zip file on my computer which is located on a NAS that “lives” outside of the network domain windows requires me to confirm 3 times a error message dialog at me stating “Windows cannot open the folder. The compressed zipped folder is invalid.”, but then it opens up just fine.

 

Yes, windows is like that..

 

Von: [hidden email] [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 08:42
An: [hidden email]
Betreff: AW: 64bit problem?

 

I am affraid, the dll file is there. Following code snipped should make sure it is before trying to load the dll

 

      if (-not (Test-Path -Path $log4netDllPathString)) {

            assert-fatal(

                  'I cannot find the logging library at "' +

                  $log4netDllPathString + '"')

            exit 1

      }

#       [void][Reflection.Assembly]::LoadFile('I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll')

      [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

and I actually can see the file with

 

C:\Users\s00489>dir I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll

Volume in drive I is WA-REF$

Volume Serial Number is 2702-33EF

 

Directory of I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release

 

18.11.2013  04:51           301'056 log4net.dll

               1 File(s)        301'056 bytes

               0 Dir(s)  137'992'851'456 bytes free

 

I cannot put the library elsewhere.

 

Maybe there is an issue because it is a network drive but I would not know why it would work on my own laptop then.

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Radovan Raszka [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 07:54
An: 'Log4NET User'
Betreff: RE: 64bit problem?

 

It looks like powershell can’t find where log4net.dll is located. As log4net is platform neutral (compiled as any CPU), I don’t think 32 x 64 bit OS is issue.

Where you have log4net.dll installed? Probably is good idea to put it into GAC.

Or put it into folder where powershell is installed. Key is to find where powershell tried to find log4net.dll – is it possible to discover this info?

Radovan

 

From: [hidden email] [[hidden email]]
Sent: Thursday, February 26, 2015 4:19 PM
To: [hidden email]
Subject: AW: 64bit problem?

 

Assuming that on either system the most resent framework gets loaded, on both systems 4.0.30319 is used. However, on the server there are both flavours, 32 and 64 bit. I do not know which one is loaded.

 

I forgot to mention that we use log4net 1.2.13, in case this makes a difference. The powershell version on the server is 3, on the laptop it is 4.

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Dominik Psenner [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 15:40
An: 'Log4NET User'
Betreff: AW: 64bit problem?

 

To be honest, the error message is rather cryptic to me. What I know is that log4net is not compiled against a specific architecture. If the targeted .NET framework is installed it should work. Have you checked that?

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:48
An: [hidden email]
Betreff: AW: 64bit problem?

 

I found https://issues.apache.org/jira/browse/LOG4NET-138 . Maybe there is a problem?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:36
An: [hidden email]
Betreff: 64bit problem?

 

Hi all

 

I am at my wits’ end. We developped PowerShell script which uses log4net. I can run the script successfully from a batch file on my laptop but on the server I get

 

Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem'

provider failed.

I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1 :

Exception calling "LoadFile" with "1" argument(s): "The parameter is

incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))"

At line:1 char:1

+ I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1

-stat_activi ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~

    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorExcep

   tion

    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorExceptio

   n,metadata_join_params-thiemo.ps1

 

 

I found http://stackoverflow.com/questions/10249406/powershell-v2-load-a-com-interop-dll which points to a possible problem with mixing 32 dlls in 64 bit PowerShell. As my laptop is 32 and the server 64 bit, I was wondering if this might cause the problem. At least I could pin the line of code where the exception gets thrown: [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

Has anyone an idea?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Reply | Threaded
Open this post in threaded view
|

AW: 64bit problem?

Dominik Psenner

Glad you were able to sort this out after all.

 

Cheers!

 

Von: [hidden email] [mailto:[hidden email]]
Gesendet: Freitag, 27. Februar 2015 15:06
An: [hidden email]
Betreff: AW: 64bit problem?

 

YAHOOOO!

 

Thanks to all so kind to nudge me to the right solution. It was a security issue after all NOT a architecture problem. I tried to load the dll on the network by [void][Reflection.Assembly]::LoadFile($log4netDllPathString) .  I did not try to re-configure PowerShell execution by global config file. But I did change the load call to [void][Reflection.Assembly]:: UnsafeLoadFrom($log4netDllPathString)

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: [hidden email] [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 14:45
An: [hidden email]
Betreff: AW: 64bit problem?

 

Thanks for the hint. I also found this configuration at http://stackoverflow.com/questions/19957161/add-type-load-assembly-from-network-unc-share-error-0x80131515

 

However, I would prefer not to change the PowerShell behavior in general. I’d rather to tweak a runtime setup. I am still investigation on that. I will let you know the outcome.

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Anthony Francisco [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 14:40
An: 'Log4NET User'
Betreff: RE: 64bit problem?

 

Older versions of .NET made it hard to load assemblies from the network. It’s much easier with .NET 4 and up by using the <loadFromRemoveSources> configuration element.

 

See https://msdn.microsoft.com/en-us/library/dd409252(v=vs.110).aspx

See also: http://weblog.west-wind.com/posts/2011/Mar/22/Loading-Assemblies-off-Network-Drives

 

So what this means is that you’ll need to update your powershell configuration file. It sounds like you might not have privileges to do that considering that you don’t have privileges to put log4net and other assemblies on the local machine.

 

-          Ants

 

From: Dominik Psenner [[hidden email]]
Sent: Friday, 27 February, 2015 03:48
To: 'Log4NET User'
Subject: AW: 64bit problem?

 

It might be a security issue then.

 

For instance, loading a dll from a network share is (from the operating systems point of view) a dangerous operation. When I try to open a zip file on my computer which is located on a NAS that “lives” outside of the network domain windows requires me to confirm 3 times a error message dialog at me stating “Windows cannot open the folder. The compressed zipped folder is invalid.”, but then it opens up just fine.

 

Yes, windows is like that..

 

Von: [hidden email] [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 08:42
An: [hidden email]
Betreff: AW: 64bit problem?

 

I am affraid, the dll file is there. Following code snipped should make sure it is before trying to load the dll

 

      if (-not (Test-Path -Path $log4netDllPathString)) {

            assert-fatal(

                  'I cannot find the logging library at "' +

                  $log4netDllPathString + '"')

            exit 1

      }

#       [void][Reflection.Assembly]::LoadFile('I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll')

      [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

and I actually can see the file with

 

C:\Users\s00489>dir I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release\log4net.dll

Volume in drive I is WA-REF$

Volume Serial Number is 2702-33EF

 

Directory of I:\WA_ANALYSE\AAA_INFA_CORE\Libs\log4net-1.2.13\bin\net\4.0\release

 

18.11.2013  04:51           301'056 log4net.dll

               1 File(s)        301'056 bytes

               0 Dir(s)  137'992'851'456 bytes free

 

I cannot put the library elsewhere.

 

Maybe there is an issue because it is a network drive but I would not know why it would work on my own laptop then.

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Radovan Raszka [[hidden email]]
Gesendet: Freitag, 27. Februar 2015 07:54
An: 'Log4NET User'
Betreff: RE: 64bit problem?

 

It looks like powershell can’t find where log4net.dll is located. As log4net is platform neutral (compiled as any CPU), I don’t think 32 x 64 bit OS is issue.

Where you have log4net.dll installed? Probably is good idea to put it into GAC.

Or put it into folder where powershell is installed. Key is to find where powershell tried to find log4net.dll – is it possible to discover this info?

Radovan

 

From: [hidden email] [[hidden email]]
Sent: Thursday, February 26, 2015 4:19 PM
To: [hidden email]
Subject: AW: 64bit problem?

 

Assuming that on either system the most resent framework gets loaded, on both systems 4.0.30319 is used. However, on the server there are both flavours, 32 and 64 bit. I do not know which one is loaded.

 

I forgot to mention that we use log4net 1.2.13, in case this makes a difference. The powershell version on the server is 3, on the laptop it is 4.

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: Dominik Psenner [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 15:40
An: 'Log4NET User'
Betreff: AW: 64bit problem?

 

To be honest, the error message is rather cryptic to me. What I know is that log4net is not compiled against a specific architecture. If the targeted .NET framework is installed it should work. Have you checked that?

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:48
An: [hidden email]
Betreff: AW: 64bit problem?

 

I found https://issues.apache.org/jira/browse/LOG4NET-138 . Maybe there is a problem?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516

 

Von: [hidden email] [[hidden email]]
Gesendet: Donnerstag, 26. Februar 2015 13:36
An: [hidden email]
Betreff: 64bit problem?

 

Hi all

 

I am at my wits’ end. We developped PowerShell script which uses log4net. I can run the script successfully from a batch file on my laptop but on the server I get

 

Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem'

provider failed.

I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1 :

Exception calling "LoadFile" with "1" argument(s): "The parameter is

incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))"

At line:1 char:1

+ I:\WA_ANALYSE\AAA_INFA_CORE\Scripts\metadata_join_params-thiemo.ps1

-stat_activi ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~

    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorExcep

   tion

    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorExceptio

   n,metadata_join_params-thiemo.ps1

 

 

I found http://stackoverflow.com/questions/10249406/powershell-v2-load-a-com-interop-dll which points to a possible problem with mixing 32 dlls in 64 bit PowerShell. As my laptop is 32 and the server 64 bit, I was wondering if this might cause the problem. At least I could pin the line of code where the exception gets thrown: [void][Reflection.Assembly]::LoadFile($log4netDllPathString)

 

Has anyone an idea?

 

Liebe Grüsse/Cordialement/Cordialità

 

Thiemo Kellner

 

--

Office fédéral de la statistique
Espace de l'Europe 10
2010 Neuchâtel / Suisse

IT-AB

Tel     +41 32 71 36516