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:[email protected]]
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: [email protected]<mailto:[email protected]>
[mailto:[email protected]]
Gesendet: Freitag, 27. Februar 2015 08:42
An: [email protected]<mailto:[email protected]>
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 [mailto:[email protected]]
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: [email protected]<mailto:[email protected]>
[mailto:[email protected]]
Sent: Thursday, February 26, 2015 4:19 PM
To: [email protected]<mailto:[email protected]>
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 [mailto:[email protected]]
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: [email protected]<mailto:[email protected]>
[mailto:[email protected]]
Gesendet: Donnerstag, 26. Februar 2015 13:48
An: [email protected]<mailto:[email protected]>
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: [email protected]<mailto:[email protected]>
[mailto:[email protected]]
Gesendet: Donnerstag, 26. Februar 2015 13:36
An: [email protected]<mailto:[email protected]>
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
