I'm retrieving the following error in a Windows Forms App (.NET Framework) by debugging execution:
And this different type of error (but in the same method) if I run the compiled exe:
Could the problem be linked to the inability to read the memory? (see the "Locals" panel on the bottom of the first picture) Why is impossible to read it?
I think the problem is memory because in the prevoius 32-bit version the application works fine, so the problem is not writing code. I'm now working at this new 64-bit version because of the 64-bit update of St7API.dll, which is called by the St7 class. I attach a few lines from this class for a better understanding.
Thank you in advance for any answers
Edit:
For other previous lines in the code there are no errors using St7API.dll. The app works fine and the error occur only when is run a specific process, maybe the the heaviest for the memory.
For the using of this API is provided a C# class (image 3) and a "closed" DLL. I add an image to the API guide for a function:
Related
I am trying to convert a windows desktop application from WinUI 2 to WinUI 3. However, I am having a problem with the Windows.Storage.ApplicationData class. When I call ApplicationData.Current (so I can access a file in the app's local data store or to get a local setting) a System.TypeInitializationException exception is thrown.
The following screenshot shows the problem:
System.TypeInitializationException
(This is a default application that I created in Visual Studio 2022 using the project template "Blank App, Packaged (WinUI 3 in Desktop)", the only change I made was to add the line to get the current ApplicationData object in the App class's OnLaunched() method:
var appData = Windows.Storage.ApplicationData.Current;)
Any idea what I am doing wrong here? I think maybe there is a trust or cababilities issue, or I should use other methods to get the app's local data folder or settings for a WinUI 3 desktop application.
I encountered the same problem recently. No matter where I made the call in my WinUI 3 application, whenever I invoked a call to the ApplicationData API, I would always encounter the same exact exception (System.TypeInitializationException with an inner COMException). I failed to find an answer in the API documentation, particularly where one would hope to find such an answer. (If it's there, it's buried or perhaps easily overlooked by someone who is not as familiar with .NET programming, such as myself.) The following line of code always threw an exception for me:
ApplicationDataContainer localSettings = ApplicationData.Current.LocalSettings;
The solution that worked for me was something I learned from a response to an issue on the WindowsAppSDK GitHub repository. To quote the information I found most relevant to the issue I was having:
A client that is not running in an App Container must open ApplicationData using this API: https://learn.microsoft.com/en-us/uwp/api/Windows.Management.Core.ApplicationDataManager?view=winrt-22000, while a client that is running in an App Container must open ApplicationData using this API instead: https://learn.microsoft.com/en-us/uwp/api/windows.storage.applicationdata?view=winrt-22000
Basically, I learned that I needed to open ApplicationData using the ApplicationDataManager class. As noted from the GitHub link, the solution I found was to replace the offending line of code with the following:
var localSettings = ApplicationDataManager.CreateForPackageFamily(Package.Current.Id.FamilyName).LocalSettings;
From there I can save and load app settings as usual, which is suitably explained here:
localSettings.Values["test setting"] = "a device specific setting";
String localValue = localSettings.Values["test setting"] as string;
Hopefully this helps anyone who finds themselves facing the same issue.
Scratch that, the problem only happens if in the debugger I put a breakpoint on the "ApplicationData.Current" line. Very weird. I think I am having the same problem as here:
Getting values of ApplicationData.Current.LocalSettings in static context
Using PCLStorage in Xamarin Forms I can create a local folder and store images downloaded from Azure.
I can then successfully test to see of the images exists using
ExistenceCheckResult fileExist = await MyFolder.CheckExistsAsync(fileName);
However, once the app has been stopped (by stopping debugging in Visual Studio) and restarted, if I run the test code above, it fails and tells me the images do not exist.
Do files then only exist for the time the app is running?
This thread looks like it could possibly cover what you are experiencing:
https://forums.xamarin.com/discussion/87498/i-am-using-pclstorage-where-are-the-files-going-to
Reading up on this, the file persistence side of things looks like debugging should not affect it, as once it writes the file - then it's in the specified location.
Also - looking at PCLStorage and the last time it was modified, if this is a new addition to your project, I can't say I would recommend it, as it looks like it is no longer being worked on, and hasn't been for some time.
I would go with an implementation from System.IO as it is now supported within .net standard 2.0 - and there appear to be lots of great examples for you to follow.
If this doesn't help, then post some more of your source code so that it can be looked into in further detail.
Im getting this error while indexing documents as an attachment. What can be the reason for this type of error. And why is it behaving differently when I run on server and when I run from visual studio.
More details about the problem is mentioned here.
Please have a look at the below link.
https://discuss.elastic.co/t/systemmemoryoutofexception-thrown-while-indexing-files-as-an-attachment/50916
TIA
I am not confident on where the actual error is ocurring. You need to determine if the error is in .net (on the client side) or in elastic? Both Visual Studio and elasticsearch will get to a point where they break without enough memory (or allocated memory) on the host machine.
If it is in elastic (check the logs - or run in console mode) - increase the heap space.
If it is on the client, try forcing your application in to 64 bit mode.
I've got a commandline C# program that compiles and runs fine using Visual C# 2010 and Windows 7. It also compiles and starts fine on Linux/Mono (2.10), but then sits there. (The program is using a 3rd party DLL to fetch data from a remote server.)
Running it in the debugger, I saw it seemed to be waiting for a DNS lookup. So I did the DNS lookup for it, pasted in the IP address. But it still hangs, and breaking into the debugger shows three threads all sitting there waiting:
System.Threading.Monitor.Wait (timeout set to -1)
System.Threading.Thread.Sleep
System.Threading.WaitHandle.WaitOne
I used MoMA to analyze the DLL. I'm not sure how accurate that is, because it matches against Mono 2.8, and I'm using 2.10.8.1, but it says Socket.Dispose() is a missing method. Then 32 [MonoTodo] items, 30 of which are Type.op_Equality or Type.op_Inequality. The other two are CredentialCache.get_DefaultCredentials() and MemoryMappedFile.CreateOrOpen().
But what got my attention was, at the bottom of the report, there are two entries for GetWindowsSocksProxy, which turns into SingleServerConnection.InternetQueryOption, and the P/Invoke library is wininet.dll. Could this be related?
So, is there anything I can do? E.g. can I copy that DLL from a windows machine to my linux machine? If so, where do I put it?
P.S. I wondered about connectivity issues. So I made a quick test Mono using WebClient, which worked fine. But one interesting difference is the non-working script loads "/usr/lib/mono/gac/Mono.Posix/4.0.0.0__0738eb9f132ed756/Mono.Posix.dll [External]" at the point where it first needs to connect to something. But my WebClient never did that.
So, I am using Matthew Ephraim's GhostscriptSharp, which is a simple C# wrapper for the unmanaged Win32 Ghostscript DLL in my ASP.Net MVC project. Some background:
What I am attempting to do is have a user upload a PDF, and then convert that document into an image that I can then save off into whatever directory I choose (as well as do some other OOP to tie that new image to my site).
I decided to use Mr. Ephraim's wrapper class (GhostscriptSharp) because it was simple enough to use, and it gives me relatively clean access to the DLL's API.
To test it, I created a dummy C# console application to make sure I could load the DLL, access it, hand it a PDF file on the local disk and then have it write a JPG to the same local disk. After a few learning experiences, I had success. I would hand it C:\INPUT.pdf, it would hand me C:\OUTPUT.jpg.
However, after integrating the GhostScriptSharp code that I had in the console application into my ASP.NET MVC project to the point of where I was calling the DLL with P/invoke, Ghostscript is returning with the int/error code -100, which is a fatal error (is called E_Fatal in the GhostScript source code). I get the same result with both the file that is uploaded through the HTML form, and if I hand it the exact same hard-coded paths that I used in my working console application.
For reference, the lines which the exception is thrown are 93-97 in GhostScriptSharp.cs (which is in the CallApi function):
int result = InitAPI(gsInstancePtr, args.Length, args);
if (result < 0) {
throw new ExternalException("Ghostscript conversion error", result);
}
Obviously the exception is thrown because result is -100.
When InitAPI is called, the instance ptr is a valid int (though I don't know if the instance of GS is correct or not), args has a length of 20 (is a string[]) of valid GhostScript options (including the correctly-escaped paths to my input & output files).
Long story short, what am I doing wrong? The error code -100 seems like a catch-all because there is no documentation that states what could possibly be going wrong here.
Any help is much appreciated, thank you in advance.
The -100 error is a generic "fatal error" in GhostScript.
A few things to check:
1) Permissions (al operations require file access)
2) Scope, you want to add the GS bin folder to the PATH variables
3) Consider not calling GhostScript directly from asp.net, GS can be very CPU intensive, rather process files in a separate service
I have also created a wrapper, send me an email (address on profile) and I will send it you. It allows one to pass in the GS bin folder which helps.
So, ended up being an ID10T error that was derailing me here in this specific instance.
In Matthew Ephraim's GhostscriptSharp code, he uses a couple of enums to define the options set forth for Ghostscript, and two in particular were the GhostscriptDevices and GhostscriptPageSizes enums. Problem is, the way they're written Resharper (Jetbrains Visual Studio plugin) has default rules for naming Enum members. Not thinking, I fixed all of these definitions to please Resharper not realizing that these are passed directly to Ghostscript, so instead of getting a7 for -sPAPERSIZE GS was getting A7, and for -sDEVICE it was getting Jpeg instead of jpeg.
For the time being permissions weren't a problem on my end, but only because I run the Cassini web dev test server in Visual Studio.
Thanks to #MarkRedman and #tvanfosson for their helpful suggestions!
Most likely the process running the web application does not have permission to write to the directories that you are using. I'd suggest creating some specific directory for the app to use and a local id to use to run the app pool, then give that id enough privileges to read/write the directory you've created.