F# interactive throws System.OutOfMemoryException when loading large objects into memory.
Exception is thrown at approximately 1.3 gigs.
Data set is 2.2 gigs, and loads fine in debugger mode.
Using VS2008 with April 2010 CTP
This is mostly a Java library that is being used via ikvmc, but if that were an issue, it shouldn't be running in the debugger either.
What is the question? What kind of data object are you loading (e.g. a large array of ints, or what)? Might be better to email fsbugs (at) microsoft (dot) com.
The fsi.exe executable has a "32bit only" flag set.
The flag can be removed to allow fsi.exe to run as a 64 bit process.
http://cs.hubfs.net/forums/thread/6369.aspx
From James at Microsoft
Related
Due to the recent problems with log4j I was checking all my code etc..
While doing so i discovered two files named
"slf4j-log4j12-1.7.5.jar" and "log4j-1.2.17.jar"
to find under
"...\Microsoft Visual Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\SSIS\150\Extensions\Common\Jars"
Since we are also developing SSIS packages we kinda rely on this extension.
Sadly I was not able to find anything about SSIS in context with log4j. IMO it's also a bit dubious that the version of the log4j seems to be 1.x, which support ended in 2015.
Are there any known fixes/updates?
This is not a problem.
In what way those .jar file can be exploited to trig a privilege escalation or software evasion?
The fact that Visual Studio is using old libraries doesn't shock me at all. Large companies are use to rely on third party library and then they are usually forbidden in the corner during years.
EDIT:
You question was somehow interesting and I needed to dig further.
Apparently this 0-day has been around since March, so it means 9 month ago. There is no evidence of mass exploitation but that doesn't mean that it hasn't been used in the past months.
In order to use it:
[...] an attacker only needs to get the system to log a strategically
crafted string of code. From there they can load arbitrary code on the
targeted server and install malware or launch other attacks. Notably,
hackers can introduce the snippet in seemingly benign ways, like by
sending the string in an email or setting it as an account username.
This means that hypothetically you can exploit the vulnerability through SSIS in this scenario:
Create an SSIS package that ask for an input to the client user
The package must use log4j for logging
The user enter the malicious crafted string of code
...then yes in this case an SSIS package could be exploited.
I will try it out in my spare time and I will let you know.
EDIT 2:
After extensive research I can confirm you that this is not a problem because only version Log4j 2.X are impacted:
Mitigation
Log4j 1.x mitigation: Log4j 1.x is not impacted by this vulnerability.
Log4j 2.x mitigation: Implement one of the mitigation techniques
below.
Use log4j-finder developed by FOX IT to enumerate vulnerable log4j files on your machines.
Microsoft have now removed the dependency
There is a new version (3.16) of the SSIS tools for VS2019 which removes the dependency for log4j.
Here's the download link:
https://marketplace.visualstudio.com/items?itemName=SSIS.SqlServerIntegrationServicesProjects
Version 3.16 Upgrade Notes
Attempting to submit a Windows Phone Silverlight 8.1 app to the store. Solution has several projects, including a Models, Contracts and a Shared DLL. These 3 projects/dlls are failing the Windows App Certification Kit tests with:
File XXX.Shared.dll has failed the NXCheck check
File XXX.Contracts.dll has failed the NXCheck check
File XXX.Models.dll has failed the NXCheck check
Microsoft say the problem is a Security threat issue, because these dlls are running code that is stored in a data segment.
The suggested resolution from Microsoft is to add the /NXCOMPAT switch to the Linker options, however, I do not have a Linker page in the properties in any of the 3 offending projects. I've tried adding this to the compilation symbols, but no change.
These DLLs are low payload - they contain not much more than POCO data objects, interfaces and a few static methods. I've built a new default blank Windows Phone app and added these projects to the Solution. If I reference any one of these projects in the main phone app project, the certification fails with the same result.
So the problem is definitely isolated to these 3 projects. There are other projects of the same type included in the solution, but these do not exhibit the same problem.
Does anyone have any ideas as to what these DLLs could contain which causes this Binary Analyzer failure?
I've compared compiler / build options and checked the project properties etc, but can't see any obvious differences.
This was due to a post-compile Build Event referencing an obfuscation library in each of these projects. Solution was to remove it as the library was third party.
I am trying to strongly name a 3rd party API that I have the code for but it's using a 3rd party DLL/NuGet Package that is also not strongly named and I'm having a lot of trouble.
I'm using the Box Windows SDK and the API was written in the .NET portable subset and supports .NET for Windows Store Apps, .NET Framework 4 and higher, SL4 and higher, and Windows Phone 7 and higher. Granted, I do not need all of these but I do need the .NET 4 and Silverlight versions. The API already works wonderfully and runs fine on its own. It would with my application also, if all my projects were unsigned but they aren't. We use strongly named assemblies for our Silverlight application in order to make use of application library caching.
Anyway, I have the source code for the API so I simply added my PFX file to the project to sign it. I then get an error that a dependency that this API is using called NitoAsnycEx.dll is not signed. I do not have the code for Nito.AsyncEx.dll but normally this isn't such a problem, more of an annoyance. So now I have an age-old problem of needing to take a 3rd party DLL of which I don't have code for and sign it with my PFX or another SNK file.
I can do either and normally I use one of the processes so wonderfully explained in this post by Ian Picknell: http://ianpicknell.blogspot.com/2009/12/adding-strong-name-to-third-party.html. So I have followed that process and the IL signing tools seem to sign the DLL just fine.
To make a long story shorter, let's use the simplest version of the signing process where I already have a simple SNK file ready to go. Basically, I do this:
I can run ILDASM to get the .il file for this 3rd party EXE:
ILDASM Nito.AsyncEx.dll /out:Nito.AsyncEx.il
I can then run ILASM to get the signed DLL:
ILASM Nito.AsyncEx.il /dll /resource=Nito.AsyncEx.res /key=NPSAssemblyKeyNoPassword.snk
It works great and I get this result:
Method Implementations (total): 118
Resolving local member refs: 0 -> 0 defs, 0 refs, 0 unresolved
Writing PE file
Signing file with strong name
Operation completed successfully
So now I have a signed DLL. I go back to my 3rd Party API code and remove the old reference to NitoAsyncEx.dll and put a new one to this. I try to compile and then I get an error like this:
Error 44 The base class or interface 'System.Object' in assembly 'System.Runtime, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' referenced by type 'Nito.AsyncEx.AsyncLock' could not be resolved r:\Data\GM\Source\GrantManagement\GrantManagement\3rd Party\Nito\Nito.AsyncEx.dll
I figure there is some problems using the portable .net library here but I'm not sure what it is. This same process normally works for me for Silverlight 4+ and Full .NET 4.5 framework libraries. Is there another ILASM or ILDASM set somewhere that will disassemble and reassemble the portable code correctly? Is this even possible?
I also tried to go and get the source code for the NitoAsyncEx.dll, which is open source btw, and compile it but that source code will not compile as it's missing some files. So currently I'm stuck with my integration of this API into my project and need a little assistance from any experts in the community.
Is there a way to sign this DLL correctly so we're not missing references to basic classes such as System.Object?
Is there a way to get around needing to sign this DLL at all and having it referenced from my projects?
UPDATED
The Box SDK has been updated and is now strong-named on nuget. This is thanks to the recent update to AsyncEx which strong-named the assembly.
As you mentioned, it's unfortunately out of our control that the NitoAsyncEx library is not strongly named. This library provides the ability to properly lock resources during an async/await call, and I do not believe there is a better alternative at the moment.
This being said, I may have a (hopefully temporary) workaround for you. I've downloaded the source from https://nitoasyncex.codeplex.com/ and was able to get it to compile. These are the steps I performed:
Removed the reference to MSBuild in the csproj
Copied the missing Dequeue.cs file from the packages folder
Resolved missing nuget references
Regenerated the AssemblyInfo.cs
Excluded the .tt template files from the project
Unloaded all other projects the SDK does not use
Here's the resulting solution:
https://cloud.box.com/s/7ikurtyajqmhq9p8q52x
I've successfully ran the resulting dll through the SDK's tests so hopefully this should cover what you need. I cannot guarantee the stability of this method, but having a working source should allow you to do any signing you need. From there, you should be able to drop the signed assembly into the SDK source and sign that assembly as well.
I've found a topic describing NullReferenceException in Windows Phone designer, however I believe this is a somewhat different issue, since it happens in all platforms and not related to MvvmCross plugins.
Designer (VS2012, Store/WP8/WPF apps) works fine for earlier versions of MvvmCross. I tried to compile a version that corresponds to 3.0.6 NuGet packages, and I can see that design-time model is loaded in all platforms.
Recent MvvmCross version causes all designer to raise NULL reference exception ("Object reference not set to an instance of an object") on all platforms.
Attempt to debug a VS instance didn't help: the call stack doesn't say much, and there is no MvvmCross code there.
The error is not related to the actual view/view model: I can remove all controls from the view, and the error is stil raised. The view model constructor code is never reached.
So it looks like there's some MvvmCross code (not from MvxView) that is unsuccessfully executed in at design-time. I wonder if this is a known issue and/or if there is a workaround to get designer work.
UPDATE. I created a GitHub issue with steps to reproduce the problem: https://github.com/slodge/MvvmCross/issues/347
This question moved to GitHub where there was lots of discussion and a few samples - https://github.com/slodge/MvvmCross/issues/347
From these samples, I believe we concluded the Nuget release 3.0.8.1 :
supports time data based on Blend-generated XML data files
supports design-time data based on simple C# classes
does not support design-time data where the data uses MvvmCross MvxViewModel as a base class
It isn't entirely obvious that developers should want to do the third thing (designtime data isn't real data?), but given that the overall MvvmCross manifesto broadly speaking aims to enable developers and to give them choice, then future MvvmCross will make this easier in the future.
In the meantime, if anyone wants to initialise objects at design-time, then there are a few helper classes around to enable this.
For example, the color plugin (and a small part of MvvmCross IoC) can be made available in the design-time environment using the MvxColorDesignTimeHelper - see:
https://github.com/slodge/MvvmCross/issues/323 (linked to MvvmCross throws NullReferenceException in Windows Phone Designer)
https://github.com/slodge/MvvmCross/blob/TibetBinding/Plugins/Cirrious/Color/Cirrious.MvvmCross.Plugins.Color.WindowsPhone/MvxColorDesignTimeHelper.cs
https://github.com/slodge/MvvmCross/blob/TibetBinding/CrossCore/Cirrious.CrossCore.WindowsPhone/Platform/MvxDesignTimeHelper.cs
After installing .NET 4.5 beta, I noticed that my calls to Assembly.LoadFrom with a network path succeed without explicitly specifying "loadFromRemoteSources=true" in the application configuration file (whereas with .NET 4.0 this used to result in "System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework.")
I wonder if this, if it indeed is new behaviour and not something special in my setups (I've not yet decompiled the respective reflection classes or debugged the loading process to examine the differences), is an intentional change in policy and will remain in the RTM version?
The docs don't seem to indicate this change in behaviour. http://msdn.microsoft.com/en-us/library/dd409252(v=vs.110).aspx. And I would have expected a notice of it.
If it does work this way, then you're granting full trust by default and invisibly to a potentially dangerous assemblies and I can't imagine that would be the order of the day.
Have you got it added to machine.config per chance?
Also I would create a small program and target it to the 4.0 platform and induce this exception. Then I would retarget it to 4.5 and see if indeed it's true. Then I'd move the binaries to another machine and test there.