When I run my command-line application from within Visual Studio, one command always fails with below error:
The program '[7316] MyProgram.vshost.exe' has exited with code -1073741819 (0xc0000005) 'Access violation'.
When I debug the code, this happens after the last execute line. Meaning the application performs it's function correctly but then crashes. When I build the project and run the exe file in the command-line I get no error and it works fine.
The project uses a 3rd party dll which in turn AFAIK calls a C or C++ dll, eg. something not coded in .Net.
My questions: Can I ignore this error since the app works fine when built? If not, what could be the potential issue and how can I solve it?
Can I ignore this error since the app works fine when built?
I wouldn't ignore the issue. If your application fails during closing, there is possibly something wrong in destructing the objects and returning the handles to Windows (most likely the latter). This might get you in a production scenario eventually.
If not, what could be the potential issue and how can I solve it?
As said, I think releasing handles is the issue. If you use some third party DLL which is written in C++, possibly there is the issue. Try to set up some logging and see what the stack trace of the exception is. This might give you an idea where the problem is caused. Maybe this is even an issue you can report back to the vendor of the DLL.
Related
I have a small application, it launches properly without debugger and all the features work except one which uses IronOcr (package from NuGet package manager). When I try to use this feature the program just closes.
When I launch this application from within visual studio, everything works fine. No errors and all features work. I get the same result if I run it and attach the debugger to it afterwards. However if I run the exe by launching the exe /bin/release and do not attach the debugger it crashes when I try to use the feature involving IronOcr.
I tested this on a virtual machine, same results with/without debugger. I then tested it on a different computer (fresh install of windows only having VS installed) it gave me this error if debugger is attached:
System.IO.FileNotFoundException: 'Could not load file or assembly 'IronOcr, Version=2021.2.1.0, >Culture=neutral, PublicKeyToken=c2cbcea5ea3f6d8d' or one of its dependencies. The system cannot >find the file specified
I've spent the last few days looking up a reason for this but I have not found one so far that fixes the issue.
What is confusing me the most is:
I assume the error that causes the program to close is the same error that causes it to give this error on the different PC. When I run it through VS it has no issues (it finds the file?) but running it from the exe it cannot find the file. I'm not moving the exe, just running it where it is in the bin/release.
I'm hoping this program will be able to run as a standalone exe.
I am still relatively new to c# and VS, the error may be glaringly obvious, or I may be using the wrong words causing me to not find a solution.
probably a bit too late, but your problem certainly comes from the fact you're using the free licence of IronOCR. It seems that this one only works when the debugger is attached.
If you catch the exception, you get that message:
IronSoftware.Licenses.Exceptions.LicensingException: IronOcr must be
licensed for deployment outside of the Visual Studio development
environment. https://ironpdf.com/licensing
In my opinion this is too restrictive for proper evaluation, so I gave up trying to use it.
Make sure IronOcr.dll is exist at same directory as your executable file.
Try to execute your application from Bin/Debug and see if it runs ok or not.
Check to see if IronOcr.dll exist in Bin/Debug but does not exist in Bin/Release. if so then copy it from Bin/Debug to Bin/Release.
I made a console application in C#, and I want to execute it from R. I am trying to run the code system(url) where url is the location of the file in the directory ApplicationPath/Bin/Debug.
I get this error when I do it: Warning message: running command ... had status 127.
Do I need to compile my code in Visual Studio in a particular way to get it to run? It's worth noting that another console application that I made the exact same way (at least I thought) does work using this method. The only difference I notice is that in the Debug folder, the one that works has a Visual Studio Solution User Options file, and the other does not. I'm not sure if that makes a difference, but if so how do you create that?
I have created a Setup file of my WPF application using Visual Studio setup project.
The setup seems installing ok and I get the installed folder and all the files that are intended to be there.
Now when I run the exe I get following error screen.
Please note when i run the application it runs pretty wel without any issues.
Please note I am using EntityFramework,WPFToolkit and log4net with the application.
And I am installing the application in the rot of C drive to avoid any restriction issue writing the log files.
Can anybody please let me know how I can track what is happening ? I tried 'try catch' in App.xaml.cs OnStartUp and MainWindow constractor returning no exceptions.
Following link has the files mentioned in the error screen :
https://www.dropbox.com/sh/2shp428xcawuk8u/mg5cyXvQ_8
My guess is that your application doesn't have write permission in somewhere.
You just need to find out where it is.
The best solution is to add a listener to Application.DispatcherUnhandledException and see what the real error is. It works even better that log4net.
Yes. my problem is very common in StackOverFlow, but I don't see the real solution for my problem yet, so I post again to hope some help for me.
I meet this error after each time I compile and run one project, and one compile and run again.
I just has one solution : open Process Explorer and kill A.exe (which A is a name of C# project).
But it is very handy, and I don't know why this very very stupid error and Microsoft hasn't fixed it, yet.
Thanks :)
When you compile and run an executable, it is in use - that means that it can't be replaced by a recompile until the executable terminates.
If you application doesn't terminate, the executable file itself is in use. A recompile will attempt to replace that file and fail.
You need to ensure this happens before you can compile again.
I have a C# Service that is calling a C DLL that was originally written in VC6.
There is a bug in the DLL which I am trying to inspect.
After having a nightmare trying to get debug to work I eventually added the dll to the VS2005 solution containing the C# Service and added the necessary _CRT_SECURE_NO_WARNINGS.
The debug version of the service is registered using 'installutil.exe' tool.
I can get the debugger to break just before the line where the dll is entered via a call to System.Diagnostics.Debugger.Break();.
I found some instruction on the net regarding stepping into debugging unmanaged code, and enabled the 'Enable unmanaged code debugging' check box, I've also tried turning on the Options->Debugging->Native 'Load DLL exports' and 'Enable RPC Debugging' (even though it's not COM). I've also copied the debug dll and .pdb to the same bin directory as the service.
However the unmanaged code is not being stepped into which is what I really need.
UPDATE: I found the Debugging Type in the DLL properties and set it to 'Mixed' as per suggestion on several sites but to no avail.
UPDATE2: My project now emits the debug dll and the pdb to the same directory as the debug service. Still unable to debug the dll.
Try setting the unmanaged code as the startup project. I know it doesn't make sense but I remember this working for a very similar project.
Since the DLL doesn't have an associated executable, when you try to run it will pop up asking what app to run. Browse to your C# app and then you should be good to go.
Happy debugging!
EDIT: it's been a while, but I think the debugging type Mixed is correct
In the end I created a console app and recreated all the prior calls just to make sure the call would act as it did in the actual service with the actual parameters once it got there.
I chronicled my fix and the resultant code at my site.
There is a workaround in Visual Studio 2013. Run the application from cmd line. When System.Diagnostics.Debugger.Break(); is hit, a Visual Studio Just-In-Time Debugger window should pop out. Check "Manually choose the debugging engines.", click "Yes" and ensure that "Native" engine is checked. Click "OK". Now you should be able to step into the native code as if you would by running the code from within VS.