I have C# application acting as a scheduler. It runs various applications successfully. One of these applications (VB6) fails halfway through the job. If I execute this VB6 application directly with the exact same parameters, it completes successfully. The scheduler runs other VB6 applications successfully. Does anybody know what could cause this? What in the environment changes when you launch an application (VB6 exe) from within another application (C#)? Maybe there is an expert that can point me to something to help solve this?
I am adding more logging to the VB6 application and currently the error points to a routine executing SQL commands, but I have other applications executing the same code with no problem. At this stage I am stumped.
The following might be different
user account / user rights
working directory
environment variables
I suggest inspecting the VB6 application with Process Explorer and comparing against a working version.
OK, I found the problem. I started by rolling back the VB6 code two versions and proved that it worked. I then added small pieces of the new code and checking every time if it still works. I did not add back all the code (some were just cosmetic) and it is now working with the new functionality. It has taken a LOT of hours and it will take a lot more to determine what caused the original error, so I decided to take the win, because I cannot afford more hours.
Related
I made a program, which works fine on my PC without any errors, it also works fine on some office PCs, but it crashes without any describable error on customer's PC and some others.
Crashes are completely random, sometime it may crash and sometimes not.
Crashes are not related with any actions, sometimes it may crash when they just look at the program and wait for crash.
Customers send me this beautiful screens and want me to solve this.
There you see common error reporting dialog, but not info about Exception.
My program uses Unity Web Player running in WebBrowser control. It's always run in background on the hidden tab which becomes visible when needed.
Any ideas how to handle such errors?
I think you should first ensure that the environment at your place and that of your customers are identical.
Maybe there're dll or other programs installed at your place (Unity web player as you mentioned for example) or anything in your Registry that may differ.
Else there's no point in getting error on one PC and not on another.
Make sure all dll are well deployed
Check your registry,
Ensure that all related programs are well installed
I have a Windows Service that runs the Excel Interop in order to automate the execution of various macros. However, I am running in a peculiar issue when I try to run a macro which access a database using Windows Authentication...
If the macro is run through the Windows Service, the workbook is opened and the macro is execution is started but the application hangs (presumably at the data access portion).
If, however, the macro is run through the Visual Studio debugger, using the same implementation as the service (they call the same class library), it executes, saves the workbook, and closes as expected.
I'm sure this has something to do with impersonation, but I can't seem to figure it out. I have the windows service running under my user and I have also modified the default COM properties in the Component Services to Impersonate instead of the default Identify.
Any help would be greatly appreciated, as it would be preferred to run as a windows service and not a console application.
Maybe I'm a bit late, but here I go anyway:
I had a similar issue and solved it by creating a Desktop folder in C:\Windows\SysWOW64\config\systemprofile and C:\Windows\System32\config\systemprofile.
It seems that Excel is not able to run under a specific user when used in a Windows service. Therefore, it runs with the LocalSystem service account, and it requires a Desktop folder in order to interact with Excel interop.
I have no further explanation, but it worked for me and it didn't cause any other know issue. I searched quite a lot for a definitive answer, but everything I found described the solution without specifying a reason.
I've never seen this issue before, and I'm not even sure if I'm posting in the correct place.
My Co-worker wrote a C# program (windows), that includes a web control. In that web control are a bunch of iFrames. Now, when the web control is populated (max 15 records), everything is fine. 99% system idle process. But once you minimize the program, boom, 99% process goes to the c# program and stays there!
If the web control is not populated. There is no issue with minimizing and maximizing the program.
There are no functions that run when the program is minimized or maximized, so there's nothing to debug...
The program is crashing on two computers, but on the rest (about 8 computers) it runs fine.
The two computers that "crash", are not very similar... so it's proving hard to find what may be causing the issue. One computer is xp, the other is windows 7, one is ie7, the other is ie8.
If anyone could point me in the right direction, or if anyone had a similar situation and has a solution, I'm all ear's and eye's!
I would attach Visual Studio to the "99% CPU" process, break all, and see what's going on in there. That's first step.
Doesn't Windows write inactive (i.e. minimised) application state to disk, to free up resources for active (non-minimised) windows?
One of the hooks / events called when you minimise the application could be causing IO hangs. You should get a diagnostics tool like Sysinternals Procmon to see if IO (or any other process) is hanging based on the minimise event.
Good luck!
Chris.
So my co-worker didn't find the thorough answer as to why it was crashing, but it was crashing due to the .net Web control. He swapped out the control for a VB6 control and it now works.
I have an application (ABC) that I developed and it as a windows application (.exe). It is by itself quite a big application referring a lot of dll's.
However, now there is a requirement that demands that this application(ABC) be a part of an even larger application (XYZ). Hence, I had to change the project type of "ABC" from being a windows application to a class library, and by changing a few lines of code.
My problem is that, ever since I started using ABC as part of XYZ, the application started hanging if I dint perform any operation on it for 10 to 15 mins... I do not have any problems while running it as a separate application.
Any reasons why this might occur?
Any suggestions would be really appreciated...
Thanks,
Ram
Launch XYZ in the debugger. Wait for the app to hang, pause the debugger, and have a look at what each of the threads in your process are busy with.
It might also help to turn on "break on all exceptions"
You can also use remote debugging to debug the application whilst it is running on the user's machine. From your dev machine, you can attach to the process on the user's machine, and then do a debug break to see what the threads are doing.
I have a WPF application that occasionally crashes, and say "not responding". Is there a way to detect if the program is not responding? And if so, restart the WPF application?
This will be a temporary fix until the bugs are fixed.
You could use the Application Recovery & Restart Manager API, which was introduced in Windows Vista. This is an unmanaged (C) API, however there are managed wrappers available in the Windows API Code Pack.
This is a good feature to add to your application anyway, as it provides the user with a nicer experience if (when!) you application crashes. You can even write a callback that persists information about what the user was doing, and then restore that state when the application restarts.
The most basic use of the API would be to just add the following line somewhere in application startup:
ApplicationRestartRecoveryManager.RegisterForApplicationRestart( new RestartSettings( "restart", RestartRestrictions.None ) );
Because this is a temporary fix while you debug the app, one possibility is to cheat and use a bootstrapper/startup app whose sole job is to monitor the problematic app. Start the problematic application via the System.Diagnostics.Process class's Start method, then occasionally monitor the returned Process' Responding property. If not responding, do what you need to do.
It's important that this only be done as a stopgap while you fix the real problem, of course. There are lots of little issues with doing something like this long-term.