I have a pretty simple wpf application. Works great on my machine. But when I install it on another machine, the browser's loadCompleted event does not fire. Based on other similar questions & answers, I have tried:
- use navigated event instead of loadCompleted - does not fire either
- use windows form browser instead of wpf browser - does not fire
- ensure app is fully loaded before navigating: tried putting the navigate call in the window's Loaded event, even threw in a 5 second sleep for good luck - does not fire
Like I said, works like a charm on my machine, both from within Visual Studio and when I execute it from the command line.
So I'm thinking it's something about the other machine. Any ideas what environmental factors would prevent the loadComplete/Navigated events from firing?
Thanks!
[edited: just tried it on another co-worker's machine, and the loadCOmpleted event does not fire there either. So it seems to just fire the event on my machine/the machine it is built on. Not sure if that gives anyone a clue to this frustrating little mystery...)
OK, well this is mildly embarrassing. The events were indeed firing, but my messagebox messages were not showing up. Before it could get to that step, the app encountered a fatal error. There were two problems that worked together to cause me days of untold angst:
1) I had deployed the debug version of my app to the two remote machines. Neither of those machines were developer machines, and they did not have the debug version of the redistributable Visual Studio gunk. So it was failing trying to load one of my dlls, because of the dependency on the debug libraries.
2) Poor error handling failed to catch this error, so it just looked like the event was not firing.
Lesson learned: make sure you have proper try/catches !!
Related
I've got a very bizarre situation. It appears that, when I load a webpage to my browser,
multiple threads (at least 2) are starting up. The app loads and runs fine on a
Windows XP box, but when I try to run it on my Windows 8 laptop it would seem that
more than one startup event is taking place and causing all kinds of collisions. This
is happening with both Firefox and IE.
To verify this behaviour, I placed a static int within a class, checked it to see if its
value is greater than zero, throw an exception if it is, then increment the int.
Of course, the exception is thrown.
What's very weird about this is that there is no multi-threading/multi-tasking involved
within my app.
When I "touch" the DLL for the webpage (rebuild it), it renders the webpage properly,
but the source for the webpage ("right click" > "View Page Source") has the source
for the unhandled exception webpage, with the message for the exception that my code
throws when the thread count is greater than zero.
I've tried creating a new project, then linking the code to it (Add Item ... Ad As Link),
then building it. It didn't do any good.
The Win XP system has IIS 6 with .NET 4.0, and the Win 8 laptop has IIS 7 with .NET 4.0.
Language is C#.
The truth is that I'm pretty much clueless about IIS.
I hope someone smarter than I am (which isn't saying much) has an idea as to what
is going on.
It appears that, when I load a webpage to my browser, multiple threads (at least 2) are starting up
Maybe onetime initializations. I doubt that every request causes an additional two threads to stay around.
it would seem that more than one startup event is taking place
That's normal This event fires for each instance of HttpApplication being created. This is basically a design error in ASP.NET. They thought that pooling HttpApplication instances and assigning one of them for each request was a good idea. It would have been better to have a singleton per AppDomain. Write this yourself. Like that:
class MyGlobalAppState { ... }
static Lazy<MyGlobalAppState> state = new Lazy<...>(StateFactory);
Be aware, that Lazy<T> stores any exception and just rethrows it. This causes your app to be permanently broken in case StateFactory throws. It will never recover without pool restart. This is a design error in Lazy<T>. Find a way to deal with that.
but the source for the webpage ("right click" > "View Page Source") has the source for the unhandled exception webpage
Some browsers re-GET the page to view the source. This can be annoying or handy.
It is hard to tell what is causing this behavior but as others suggested try to use Fiddler or any other http tracing tool to see what requests are sent.
Also, Win XP should be running IIS5.x while Win8 should be running IIS8.
By default IIS8 AppPool should be running with the integrated pipeline, which may behave differently. I would try changing the AppPool to use the Classic pipeline to see if it makes a difference.
It looks like a duplicate, but believe I checked other answers, nothing worked.
My application started crashing while closing the application with below error. It was working properly few days back, some recent changes is causing the issue. And one this starts on a machine, even though I replace with previous working DLL, still the issue comes.
Microsoft Visual C++ Runtime Library
Runtime Error!
Program:C:\DigiMic\...
This application has requested the Runtime to terminate it in an unusual way...
This pop-up comes for 1 second with OK button, then automatically closes. The main problem is it happens while shutting down my application.
My Application: It is a WPF, C# application which uses Matlab used business DLL for few functionality. The application works fine while using the Matlab used DLL and its function, only crashes while exiting the WPF.
I tried to Wrap the App.Current.ShutDown with try..catch... but the it never hits catch orfinally block. Then I also tried AppDomain.Current.UnHandledException += new..., it still does not hit the function on exception.
The other problem is, I am not able to see the complete path of the exe that causes this exception.
Question:
Is there a way, I can suppress this error?
Where is this error gets logged in windows?I tried to look into Event Viewer, but nothing is there.
Is there any workaround? Since it's software delivery time for the product. :(
I've been writing this program for a while now, and I'm finally ready to start testing it. It works 100% on my dev machine, but I wanted to try it on a machine it's never run on. So, I get my program over to a test computer. When I double-click the exe, nothing happened. I opened up task manager, and tried again. I saw the process start, but after about 5 seconds, it disappeared. No errors, no exceptions, no nothing. How would I go about trying to figure out what is going wrong? I'm still fairly new, and I've never had this happen. Thanks for any and all help!
EDIT
Sorry for not mentioning before. This is a winforms application.
EDIT 2
So, turned out what was going on is that I was trying to a dll meant for 64-bit OS into a 32-bit OS. In Windows XP, this threw a BadImageFormatException. However, in Windows 7, as I stated, it threw no exception at all.
This is a pickle, no doubt about it. I've had to debug this type of thing before.
The first bit of useful information is that no exception is being thrown out. This tells me that somewhere in your actual code is the key to solving the problem. You are either trapping an exception and closing silently, or your code is hitting what it considers to be a "normal" exit condition and is closing in what it would consider the normal way.
To figure out where and why it's exiting, I would add debug logging at key points in your application, and attach a listener to the Debug/Trace listener collection that writes out to a file. "Key points" are places where the application is supposed to exit (or the main form of the window is supposed to close), and within any "catch" block or error event handler. Run this new version on the test computer and see what it gives you. That should tell you the basic flow of the program behind the scenes, and through what mechanism it's shutting down.
If you're running a console application, it is possible that it runs and then closes itself.
Trying opening a command prompt, and then executing the application from there.
If your program has output, then you would see it in that command window.
Have you checked the application event log?
Do you have the necessary version(s) of .Net installed?
Perhaps you should put more exception handling with calls to MessageBox.Show("I failed here") through out your application.
I'm working on the Kinect, and sporadically the Kinect makes Visual Studio Crash.
It's happening when I call the kinectSensor.Start() method after debugging I found out that the Kinect is already in use in another process.
But no other processes is using the Kinect!
It happened one time on the morning after booting my machine and launching the app.
But most of the time it occurs when I launch the Kinect App (in debugging mode in VisualStudio 2010), I stop the application and after some code modification I re-launch the app and that time it doesn't work, I've got the above exception and after 2sec Visual Studio crashes.
Moreover I check if the Kinect is already running and this is not the case (below the state of the Kinect sensor during debugging):
The weirdest thing above all is that sometimes it works fine for weeks, and after that it makes that thing for two days every two/three launches of the app.
The only solution I found on the subject is from one guy with a very similar problem (the only one on the internet?) : Imad Elayyan
When I launch Process Explorer I found the exact same problem of USB port handling (shown on the photo), a mutant process which is not terminated when we close the app.
But his solution is not really a long term solution: I have to kill manually the mutant and re-start VisualStudio. Sometimes I have to restart VS 20 times on the morning...
Is there a way to properly close that handle of the usb port (in code?) so that when I close the app it terminate that handle and doesn't makes VS crash anymore?
Any help would be appreciated, it is really puzzling me and it drives me crazy.
Additional information:
i'm using the SDK1.5 + Kinect for Windows but it was also the case with the SDK1.0 + Kinect XBox360
I've already try to debug VS with another instance of VS.
Ok guys, thanks for caring. I think I found the source of my problem but I still lack an explanation for the handle port.
Facts:
I have 3 projects in my solution, two classes library: Kinect.dll
which create the connection to the device, handle the gesture
recognitionj part and the cursors creation. KinectControls.dll
which create controls (button, border, chart 3D...) that can
interact with the cursors. And a test project.
Kinect.dll launch the event of the Kinect + some custom event:
ColorFrameReady, DepthFrameReady, GestureRecognised...
Most of the event are internal in the assembly, but some are visible
from outside classes.
Each event registered is unregistered (or so I thought).
I implemented the facade pattern for the Kinect-related
classes. KinectFacade posseses a KinectStop method which close the
connection and unregister events.
Root of the problem:
When the application was shutting down, the Application.Current.Shutdown() method called KinectStop which stopped the Kinect and the unregistered the handler in the assembly. But in the outside assemblies the unregistration was called after the Kinect closes (even if the unregistration was called on Application.Current.Shutdown() too) which led to a 'basic/usual' error. So that I removed the unregistration.
When you do not unregister of the Kinect event and the Kinect closes (KinectSensor.stop() method called), it (sporadically) keeps the USB handle even if the application is closed and any thread terminated!! And after that: No way to reopen the application (Kinect.Start() crashes) and finally when you try to close Visual studio it crashes (as explained in my question).
Solution I've found
When KinectStop() is called I use a timer before closing the Kinect so that every classes in outside assemblies can unregister events.
Moreover from now on no 'normal' event are available from the outside classes: the façade handles those events and raises FastSmartWeakEvent which are available from the outside world. It solves memory leaks and could also solve my problem in some situation.
Since then not handle USB port is keeped and Visual Studio do not crash anymore.
Summary
I've found the roots of my problem and a solution in order to bypass it. I hope this will help anybody with a similar problem.
However I'still don't understand why closing the application and/or calling KinectSensor.Stop() method from the SDK does'nt close all events handler/Threads/processes/Port Handle. And why closing visual studio make it crash even if one of the previous is still running?
If anyone has a suggestion it will be welcomed?
Make absolutely sure the Kinect is plugged into a USB 2.0 port and NOT USB 3.0.
Microsoft Kinect does not support USB3.0 and all kinds of crazy behavior results from using one with Kinect.
I was experiencing many of the same sporadic issues as you and the problem was solved when I began using one of the few USB2.0 ports on my machine.
Try windows collider. It will solve your problem easily.
There is a program where I work that works fine when running the .exe file but works differently from expected when opened in VS2005 and played from there. I am therefore asking on here if anyone knows of anything that would work in the .exe file but not the debug from VS? I am not able to post the code for the buttons I'm talking about but I'll try to explain the best I can.
There is a receiver hooked up to the computer. When the button is pressed on the program, it shows a message and waits for a signal to be received. After the signal is heard the first message box is supposed to close and another is supposed to open. When using the .exe file this happens just fine. However when playing from the program from VS2005 (the same one from which the .exe was made) the second message doesn't come up when it is supposed to and when I can make it come up, the first box doesn't close. There is also a timer involved if that helps.
Also, is there a fundamental difference between how the two operate when executing the program?
If I need to make anything more clear or give more details please let me know.
Running a program under the supervision of a debugger can change the timing of events compared to running the program standalone. The debugger slows things down. Normally, this doesn't make any difference to the operation of the program, but if you have code that is dependent on the "coincidental" rapid timing of some activity, that happy coincidence may be broken when things slow down under debugger control.
The debugger can also cause changes in focus and activation depending on where you set your breakpoints - generally not a good idea to set a breakpoint in focus change or activation events because stopping at the breakpoint will change focus to the debugger, away from your app. But these are interaction issues. Just running your program under the debugger with no breakpoints shouldn't affect focus or activation in your app.
Review your code carefully. Consider what could happen to your program flow if you inserted delays between every source code statement. If that could lead to problems, you have a design bug that needs to be fixed. Reliance on coincidental timings will lead to bug reports and support calls, particularly if your customers have slower hardware than your development machine.
When you run under the debugger, or even in the VS testing host, there are some subtle differences. This shouldn't effect your program under normal circumstances, however, since most of the differences are similar to running (the debug version) of your application on a slower system.
Given your descriptions, I suspect that your problem is actually due to calling to the UI from a different thread than the control was constructed with. Make sure to always marshal any calls to the UI using Control.Invoke or Control.BeginInvoke.
It may be an issue with the Host Process, disabling it is a painless click and just as easy to re-enable. It may be worth giving a try.
Disable Host Process
I know this can effect Direct X and other API but I've never had exactly the situation you are in so I make no promise.