I've got WinForms application that I'm constantly developing on Windows 10 machine. This application is deployed then to windows 2003 server where some before release tests are performed. The problem with null reference exception occurs when application is closing. What are typical approaches in such situation to check what's the problem is. This issue occurs only on these machine, I can't install visual studio here. What should I try to use to discover such issue?
If you deploy the PDB symbol files to the test environment you should get line numbers in your exception stack traces.
Beyond that you might be able to install the remote debugging tools and connect to the failing instances from your development IDE.
You could also log messages to a file to help you narrow down the issue.
Related
I have developed a windows service, I can debug it using visual studio and it works as expected. But if I install the service using the installUtil.exe and start it I'm getting the following exception:
System.Runtime.InteropServices.SEHException (0x80004005): External
component has thrown an exception.
I tried cleaning the solution, uninstalled and re-installed it. I even restarted my computer but nothing changes. I tried running the windows service with my local administrator credentials but the result is the same. I can install and start the service successfully on my coworkers computer. What do you suggest to me to start the service successfully on my own computer?
I had a similar problem, where a C# service application installed on one particular computer failed to start, with the same error as above logged in the Windows Event Log.
Deleting the application's installed executable file and copying it manually from the installer image solved the problem. Hence it appears that a corrupt file can lead to that type of SEHException.
I've been refactoring some code which was previously working.
Now when debugging I get to a break point in the refactored code and when I step into the Property in question I get a message saying that Windows firewall is currently blocking remote debugging.
It doesn't make sense because the application is a console application being debugged through visual studio on my local machine. I am using VS2010 and .net 4.0.
Does anyone know why vs might be trying to remote debug?
what does your code do? does it access any external files and or databases?
It could also be an administratrion issue, try rightclicking VS and run as admin first off and see if that fixes the issue.
secondly trace your code and see if there is any links to externals, and thirdly go to windows firewall and change the settings to allow access to Visual studios~ and or databases/.net instances.
I have been working on an application using .NET 4 and c# in Visual Studio 2010 Express. It's purpose is to watch a directory and import any documents it finds into our imaging system.
I included an installer class which provides the information needed by installutil.exe.
So to install locally, I build the solution, and then at command line:
installutil.exe MyProjectExecutable.exe
Which installs it as a service. This works fine in my development environment.
To deploy to the test environment, I use the same method:
installutil.exe MyProjectExecutable.exe.deploy
Except of course the executable has a second extension, .deploy. This is the way the application is published by Visual Studio. Everything works up tot his point
Here is the problem: once I have done this, I run the service and it starts properly, as indicated in the log file. However, once it detects files in the directory, the service will not do anything with them and will eventually crash. The only way I can tell it has crashed is to look in the windows Event Viewer. It will show the message:
"An unhandled win32 exception occurred in MyProjectExecutable.exe.deploy [4108]. Just-In-Time debugging this exception failed with the following error: Debugger could not be started because no user is logged on."
Two questions:
1) What could be causing this
2) Am I going through the correct steps to install a windows service, or is there a better way?
Both environments have .NET 4 installed.
In both environments I am placing the same documents in the import directory.
In both environments the service runs under the Local System account.
If my question reflects a lack of C# experience, my apologies in advance.
subscribe to AppDomain.UnhandledException Event
Are you watching a directory under 'Documents and Settings?' You mention that you're running under Local System, but is that in the C# code or in the Services Panel?
Start->Run
services.msc
< Find your App >
Right-click, Properties
Log On Tab
Log On As
This Account
< Plug in a user / pass with permissions >
In my experience this it is always a security problem. Check the rights that the service running user has. Can it access the folders you are monitoring and make the needed changes?
I have found the problem. in the config file, the listen directory was "c" whereas it should have been "C". Until now, I didn't think Windows was case-sensitive. Thanks for the help guys.
I am trying to remotely debug wcf service on IIS 6. It has been working fine until yesterday. Now breakpoints are not being hit and warning message says "No symbols have been loaded for this document". I've solved this by restarting iis and app pool, but it worked just for a few days. Now I have the same problem. I've read almost all advices on the Internet about this, I've checked build options, GAC, ASP Temporary folder. When the service file is loading the VS is writing that my dlls is loaded. But when I looking at the debug->modules window it shows that this modules haven't been loaded. I still can see exceptions while debugging. Now I am temporarily using Debug.WriteLn() for debugging, but it takes a lot of time and effort. Any help will be appreciated.
P.S. I use VS 2010, WinXp Sp3 on my PC and Windows Server 2003 on server.
[Updated] Is there any patches for VS 2010 that can fix remote debugging problem ?
[Updated] I've noticed that w3wp process type is x86 now, although my service was called by client before and it should be managed type.
Finally, I 've found a solution. I copy my WCF output files to the same location on the server as in my pc. It is quite wierd but debugging works perfect.
Here is your answer, and the issue I ran into:
I've noticed that w3wp process type is x86 now, although my service
was called by client before and it should be managed type.
Typically to get the w3wp.exe process to actually show in the Attach to Process debug dialog is to just browse to a site in IIS locally. This will spin up that process and make sure it is available to select.
However, you must browse to a site using the same app pool type as the WCF service you want to debug. If you select an app pool using a 32-bit process (x86) and attach to this for a WCF service expecting a x64 version, the resulting "No symbols have been loaded for this document" will be displayed and breakpoints will appear as 'hollow' red circles.
First: Please Install IIS 7, its much recommended!
2nd: it happens sometimes with everyone I guess, deploying the service again with the options (Delete existing files (checked), with source code (checked) ), resolves the problem.
Actually that's the only solution is working in my case
Regards,
Mazhar Karimi
I have built a WIX project which installs and starts services. For the release version it all seems to work fine but for the debug version I get "insufficient privileges to start service". Any clues why this is happening?
Using .net/Visual studio.
JD.
In my experience this error message is always misleading. Typically it's actually a fault of the service exe. With the messagebox displayed, go to a dos prompt and run the EXE. You'll most likely see a stack trace get displayed. If you see a File Not Found Exception then you are probably missing a dependency. Any other error and it's likely to just be a problem with the code.
Typically when integrating a new service into my installs I will set it to start automatically but not author any specific start events. This lets me work the kinks out with the developers before wiring it up fully into the installer.
Most probable cause: It works on computers that have (or have had) Visual Studio installed, because it means they have debug version of run-time libraries installed as well. It does not work on computers without Visual Studio.