I have a program that I built that reads and writes files. I built it in Release mode, then tried to run the exe on Win7. At first, with troubleshooting on, Windows simply told me the application closed and it was looking for a solution. After a few seconds, the dialog would disappear and show nothing more.
So with some significant effort I got the debugger attached to the process, but it was only showing me disassembly, which tells me that the error taking place wasn't in my application code, but in the framework somewhere.
The strange thing is that when I let the debugger attach, then press "stop" in VS, and exit the debugger, the program actually runs at that point!
So now I'm stumped. I have an application that builds, that seems to be having a permission error when I run it, but if I let the debugger attach then close it, it runs, and there's no Exception to really look at.
How I troubleshoot this issue?
Edit: Responding to Merlyn:
It's a custom app written from scratch in c#. The only dependency it has outside of core .NET namespaces is the Ionic.Zip DLL.
Visual Studio 2008 (Writing in C# 3.5)
Windows 7 - Home Premium, v6.1 build 7600
CPU - x64 quad core
CPU are you compiling under: Any CPU
I haven't tried it on another machine or a different version of VS.
Edit: I was able to try the compiled version on another win7 computer, and it worked without issue, so it looks like a security (?) issue on my computer only.
Try it in the debugger with Just My Code disabled and Native Code enabled, then check the call stack.
Also, what happens if you run it directly in Visual Studio?
Uncheck Enable Visual Studio Hosting Process in Project Properties and see whether it still works in VS.
I'd suggest sending the issue to Microsoft support. Especially with the data given here, you will have an easy time convincing them it's their problem. You might need an MSDN subscription for that.
Related
I've upgraded my Windows to 10.0.16299 (latest) and my Visual Studio to 15.5.1 (latest). Since then, I am seeing this error message when I clean or build my Xamarin solution containing an Android project:
obj\Debug\android\src\android\support\customtabs\CustomTabsClient_CustomTabsCallbackImpl.java:4:
error: error while writing CustomTabsClient_CustomTabsCallbackImpl:
obj\Debug\android\bin\classes\android\support\customtabs\CustomTabsClient_CustomTabsCallbackImpl.class
(The process cannot access the file because it is being used by
another process)
I figured that the locking process is Visual Studio itself after I tried to run and debug the app.
The issue appears no matter whether I want to run the app on an emulator or a connected real device.
There's lots of advice what to do when a process locks a file including SO such as the famous the process cannot access the file because it is being used by another process. However, all provided answers don't help as Visual Studio itself locks the file and the only workable workaround is to restart Visual Studio - that's not a solution.
What is causing this file to be locked? Any idea? Any advice?
Sometimes it helps to kill the MsBuild.exe. Also, you could find other solutions such as described here: Xamarin Android project cannot build....
Basically, it seems to be a problem with Studio 2017 Version 15.5. It will be fixed with the next versions probably.
Darn it, my suggestions won't fit in the context of a comment, so here goes:
Sounds like the process being debugged, or the emulator hosting the debugged process, itself, has not fully closed down, and is in a hung or semi-hung state. Have you checked the process manager to see if this is the case? You may want to to try adding Environment.Exit() to see if this helps come back to a good state.
Another thing to check is, whether your access levels are the same between the two machines. Check not only the PC, but also at the emulator as well. Check everything, and ensure the access levels/modes are identical.
Finally, try running VS 2017 in administrator mode, and see if the problem persists. It's entirely possible that the level of access that you used to run pre-Windows 10 is different in the Win10 world that you live in, now.
I develop C# applications using VS 2010 Ultimate.
Usually, those applications run for long time, without user interaction and, of course, they usually have bugs inside.
Unfortunately, often the application crashes randomly and you just can't reproduce the error. Also sometimes I only have the message "The application has stopped working" with no more informations.
I can install Visual Studio on the machine of the customer, but I can't let him run VS and compile/start the source code in debug mode! What I need is to start VS after the application was started and crashed. It seems to be possible to do this, in fact when an exception happens at runtime, Windows ask you "do you want to debug with VS?", but if I answer YES, then VS starts but simply I can't see the source code (it is on the pc as well), thus I can't inspect the row of code that is causing the exception. VS just tells me "source code not available". Actually, I can't imagine how Windows could start VS and know where the source code of the crashed application is!
Does anyone knows how does this debugging scenario is intended to work, and how to configure it??
Thanks a lot,
Simone
Windbg debugging tool solves the purpose.
Take dump of the process state and start analyzing with windbg. It gives you the exception information
To debug from an already-running Visual Studio instance, select the "Debug" menu item, then "Attach to Process..."
Next, select the executable from the list, press "Attach" (or double-click), and you are now debugging the application. When you select "Yes" and Windows says that source code is not available, this most likely means that the PDB wasn't able to be loaded, so make sure that you have loaded the symbols for the module by examining it in the "Modules" window pane.
If you want to catch errors while running compiled program, you should use some sort of logging mechanism. These days you don't have to write it on your own, there's a great opensource logging engine designed for .NET applications, it's called NLog. It's capable of saving logs into files, emails, console or database, pretty much all you can want :).
Hope this helps :)
I am working on a WPF application.
Which is running fine with "Any CPU" as Active solution platform, but when it is changed to "x86" application starts but stoping without showing up any form or error message.
Application neither throws any exception nor logging any error in event log.
I am running this application on .NET 4.0 framework and Windows 7 64 bit OS.
appreciate your help to solve this issue.
Thanks,
maxk
First off, it's strange that you don't get any error messages. Not even when you launch the built application without debugger?
The best answer anyone can give based on the information provided, is to do some trial and error debugging:
1) Create a new empty project, set it to x86, see if it runs. If not, there is some serious problems with your machine setup, you'll probably have to reinstall.
2) In your own project, if you have any external references start removing them one by one and see if your app starts to run. Maybe a referenced dll is causing havoc in 32-bit mode.
3) Start commenting out blocks of code to see if your app starts to run then. I've found out that having errors in Window_Loaded methods (especially while debugging) can cause problems - exceptions not being handled, application crashing etc.
4) Could be that you have a bad Visual Studio plugin (I assume you are using VS and problems are occuring on your development machine). Try running the app without debugging...
5) Create a virtual machine and try your app in there, if it works there, then your machine is somehow "corrupted"..
PS! Just for your information, because you are running a 64-bit OS, then the Any CPU setting causes your app to be 64-bit. Forcing it to be 32-bit can cause problems if you are using badly written native dlls (although it's usually the other way round - problems occuring when going to 64-bit from 32-bit).
I have an app that I wrote using C# .NET 4.0 in Visual Studio 2010 on my Windows 7 Ultimate machine. This app works fine on both Vista and other Windows 7 computers, but whenever someone running Windows XP tries to run it it crashes.
In order to reproduce this I've tried running it on my Win XP VMWare machine and it crashes for me in there. Unfortunately it doesn't give me any specific error, just informing me that the program has crashed and needs to close.
One other user sent me the following:
Run-time error '339'
Component 'vbalSGrid6.ocx' or one of its dependencies not correctly registered: a file is missing or invalid.
Code 0xe0434352
Flags 0x00000001
I don't get that particular bit when I try to run it on my Virtual XP machine, and I also made sure to install .NET 4.0 on there.
What could be causing this, and why won't the app run in XP if the .NET 4 framework is supported for XP?
Components used in the program: DataGridView, ComboBox, Buttons, Labels, LinkLabel, NewtonSoft's JSON parser, and that's about it.
I am baffled and have utterly no idea where to start. Ideas?
UPDATE: Hmm, tried running my other recently created application on XP and it loaded fine. The only major difference (in the components I used anyway) between the two is my use of NewtonSoft's JSON library, which I actually think is a .NET 3.5 component.
UPDATE 2: Just for kicks I tried running the program on my Wind7 machine in "Windows XP SP3" compatibility mode and it ran fine. Of course, I have no idea just how closely the "compatibility mode" emulates a true XP SP3 environment, but I figured I'd give ya'll the info anyway.
¡¡ IT WAS THE APPLICATION ICON !!
I kept noticing that the module it referenced in the error it gave me was system.drawing which I thought was odd. I figured perhaps the PictureBox I was using was causing the issue, so I tried disabling everything to do with that, to no avail.
I had my business partner set up his XP box so that we'd have another machine to test with aside from my VMWare XP box just in case there was some odd issue with it.
After he got it set up and the app copied over he said "The icons look like DOS ones" and I had a eureka moment.
I was using .PNG's as the icons because they support transparencies and whatnot, but XP doens't natively support them. So when the app was copied to the desktop it just used a generic icon for it, and when the application was run it crashed because XP doesn't know how to render a .PNG.
Try using the Fusion Log Viewer to debug startup errors in .NET applications.
Scott Hanselman has written a nice howto along with links to further resources if you need to go deeper.
Are we sure this is some wierd .NET compatibility issue or just a run of the mill bad installer/deployment problem?
Here's one user who has that error message because the OCX DLL was copied to System32 with a shortname. Renaming the DLL to the correct name and running RegSvr32 resolved his problem.
Do you have an installer? Have you correctly identified all of your managed and unmanaged dependencies and properly authored them into your installer?
http://forums.elmsoftware.com/forum_posts.asp?TID=119
I have the source code for a C# project (which wasn't written by me) which I run on one of our servers.
There is a particular part of this program (a menu option) which occasionally fails silently and I can't figure out why from just looking at the source. (The part of the program that fails requires various features that are not on my development machine, so I can't test it on my own machine).
I would like to debug this program and in particular step through the code line by line. Since the server is outside our firewall, remote debugging feature will not work.
Is there any alternative other than installing Visual Studio on the server, ie are there any runtime debuggers that will show the C# source code and allow you to set breakpoints etc?
The project was written in VS 2008 and targets Framework 2.0.
You should be able to use DbgClr for a framework 2.0 app. It is a standalone graphical debugger that comes with the SDK. You will need to ensure that the PDB files, that matches the running build of the application, are available to the debugger.
That being said, if you have any option to punch a hole in the firewall, so you can use remote debugging, that would probably be the easiest way to go.
Of course, it would be best practice to setup your local environment so you can reproduce the bug and debug locally; but I can understand if there are reasons that might make this unfeasible.
Another option is to use WinDbg with the SOS extensions. It's an extremely light weight debugger that doesn't even require the .Net framework to be installed. It leaves much to be desired in the way of UI and has a steep learning curve. But once you get the hang of WinDbg it's an amazingly powerful debugging tool.