I have a UWP App that implements Cortana functionality to navigate pages. I'm deploying it in VS2015 Community on the Debug/x64 configuration.
I can say "open {my app}" and it works fine, then "open {my app} to {book} and {chapter}" and it works fine if the app is already open. If the app is not already opened and I say "open {my app} to {book} and {chapter}" it will try to load the app and briefly show the screen before it disappears, presumably from a crash.
I need to debug and figure out what it's trying to do when the app is not already opened. Is there a way to do so?
I need to debug and figure out what it's trying to do when the app is not already opened. Is there a way to do so?
Of course you could trigger suspend, resume, and background events for Windows Store apps in Visual Studio. The following is the brief testing procedure regarding uwp application lifecycle events.
In the Visual Studio debugger, you can manually suspend, resume, and terminate your apps to debug process lifecycle events. To debug a process lifecycle event:
Set a breakpooint in the handler of the event that you want to debug.
Press F5 to start debugging.
On the Debug Location toolbar, choose the event that you want to fire:
Note that Suspend and terminate closes the app and ends the debug session.
Related
A bit of a general question perhaps. I have an app that is quite simple, basically a wrapper app for a webpage. This app crashes on WP8, and it happens usually when you start the app, then go to the home screen and hold the back button to bring up the recent apps view and go back into the app. The app is just killed.
What I am wondering is that before when I have had problems with a WP app crashing on WP7.5 I would run the app on the phone from Visual Studio Express and when the app crashed I could see the error and stack trace in VSE. But with the error I am having now its as if VSE doesnt even know that the app has been terminated. It still shows that it is running.
One thing I tried was to add event handlers for the onNavigatedTo event and set a breakpoint in there to see if I could catch the app when I was switching back to it and then do step by step from there. But when I did that and the app crashed all I got from VSE was a message saying that it had failed to bind the breakpoint.
I also tried the emulator, hoping it would give me better insight but its the same as running the app on a phone. So now I have an app that is very unstable on WP8 (works solid as a rock on WP7.5 though) and I have no idea what exactly is going wrong.
So my question is if there is any way to get more information on how and why the app is crashing :)
You also can use the Event View of Windows.
I have a similiar problem (sometimes while running and accessing the isolated storage the app just gets killed without any notice) and the event views provides some useful information.
I'd suggest to put debug output (Debug.WriteLine) in App_Activated and App_Closing methods in the App.xaml.cs file. And also to the RootFrame_NavigationFailed and Application_UnhandledException. All those methods has a potential to run when you return to your app and it crashes. If this would not help (you'll see no output in VS Output window), try putting some other output there, like writing synchronously to a file in the isolated storage, or activate some launcher (like email compose task, see here). The point here is to perform some other activity when failure happens.
Another thing you could try is to break execution in VSE, when app is already seems to be terminated. I mean, pressing the "pause" button in the debugger. It could potentially be informative.
I have tried two installers - Setup2go, and Installmate Builder, and I have the same problem. At the last window of the install, I select the option to "Open program after installation finish", and sometimes (about 10% of the time?), my (Winforms) app's main window will open behind the Windows Explorer directory window I used to open the installation exe from.
The frustrating thing is - I am having trouble reproducing the problem reliably (the problem seems to occur around 10-20% of the time). I am using Windows 7 if that makes any difference. To clarify, if I open up the executable directly (rather than from the installation exe), the problem never occurs.
My knowledge on this kind of thing is limited - I recall a similar frustration happening with the MessageBox from this question
Any ideas?
It does not happen when you launch the app directly from installer because the shell allows it to “steal” the focus. When you launch it from the installer, the last interaction happens in the installer app. The system prevents the new window from stealing the focus from your installer. If installer window closes, then the explorer window which you used to start the installer is activated. Since the switch of the foreground window happened recently, the system does not allow to change the foreground window.
On the other hand, if your application window is shown before the installer window disappears from the screen, the the app will be placed below the installer in the Z-order; and when the installer window is finally hidden, the application window is activated.
So it's all related to timing between showing and hiding windows.
Although I am not expert in this area. You can use message tracers and WinAPI calls tracers like Spyxx which can give you more details on what happens in the system and why the new window of your application is placed below the Explorer window.
Make sure the window's title isn't changed, until the last possible moment. I moved the Text = "blahblah" line out of the Form_load event, and into the Form1_Shown event, and now the hidden taskbar icon problem has vanished. Also, the window doesn't flicker when it's loading.
For two weeks, each day since I installed Windows 7, I have been struggling to get something to work. Something which worked perfectly ok in XP. It's driving me mad, poisoning my life, ruining my days. Why such a simple task works SO CHAOTICALLY!?
I think I discovered a bug in Windows 7, specifically in the way the ShowWindow function works in the standard theme (Aero).
To demonstrate this, I uploaded 2 C# WinForms applications and their source code.
http://www.axonnsd.org/W/P007/BugsDemo.rar
HideableApplication represents an application which you can hide in the SysTray when you close it. Double clicking the SysTray icon reveals it and right clicking will reveal the "Exit" option.
HideableApplicationRevealer attempts to show HideableApplication's window.
The reason I need to accomplish this task is because I minimize my Total Commander and FireFox to the Tray and I want to bring them back via a HotKey. Total Commander offers such a functionality but it is broken.
On Windows XP I managed to accomplish both these tasks without any problems, using the code I attached.
On Windows 7, the behavior is erratic at best, and non-functional at worst.
When HideableApplication runs inside Visual Studio everything works:
Trying to reveal it via HideableApplicationRevealer from Visual Studio => SUCCESS
Trying to reveal it via manual execution of HidebleApplicationRevealer.exe from Debug folder => SUCCESS
Trying to reveal it via running HideableApplicationRevealer.exe via keyboard shortcut => SUCCESS
Trying to reveal it via running HIdeableApplicationRevealer.exe via a Scheduled Task with Admin Rights => SUCCESS.
When HideableApplication was executed manually (via .exe from Debug folder) AND Visual Studio IS STARTED, it works if I use admin rights or run it manually:
Trying to reveal it via HideableApplicationRevealer from Visual Studio => FAIL
Trying to reveal it via manual execution of HidebleApplicationRevealer.exe from Debug folder => SUCCESS
Trying to reveal it via running HideableApplicationRevealer.exe via keyboard shortcut => FAIL
Trying to reveal it via running HIdeableApplicationRevealer.exe via a Scheduled Task with Admin Rights => SUCCESS.
Trying to reveal it via running HideableApplicationRevealer.exe via keyboard shortcut (start menu) which has been given ADMIN RIGHTS => SUCCESS.
When HideableApplication was executed manually (via .exe from Debug folder) AND Visual Studio HAS BEEN SHUT DOWN: it only works if I run it manually (double click exe):
Trying to reveal it via manual execution of HidebleApplicationRevealer.exe from Debug folder => SUCCESS
Trying to reveal it via running HideableApplicationRevealer.exe via keyboard shortcut => FAIL
Trying to reveal it via running HIdeableApplicationRevealer.exe via a Scheduled Task with Admin Rights => PROBLEMS: Window blinks on the TaskBar instead of being shown!
Trying to reveal it via running HideableApplicationRevealer.exe via keyboard shortcut (start menu) which has been given ADMIN RIGHTS => SUCCESS.
If it matters, I reproduced this behavior both with the Taskbar in its standard position AND also with it set to AutoHide, in the left of the screen.
Apparently, I need admin rights to show a window, but even like this, it doesn't work right when I use the Scheduled Task workaround (create Scheduled Task with admin rights and invoke the Scheduled Task via system32/schtasks.exe /run /tn "task name"). What happens is that AFTER VISUAL STUDIO IS SHUT DOWN, the window blinks on the TaskBar instead of being shown (and has no focus). It does appear, but it has no keyboard focus, which should NOT happen because I also used the SetForegroundWindow API.
This is exactly what happens when I try to run reveal Total Commander as well: read below, same behavior: blinks on taskbar instead of being shown.
And don't even get me started on the difference in behaviors between when running it from Visual Studio and when running it from its usual C:\MyProjects folder.
My TotalCommanderRevealer and FireFoxRevealer exhibit even stranger behaviors: when starting Visual Studio, the Total Commander app stops working properly. Even if I load NO PROJECT, instead of showing TC to me, it just blinks it on the TaskBar. However if I open the TCRevealer project, it starts working again! If I shut down Visual Studio, it STOPS working UNTIL I RESTART WINDOWS.
The FireFoxRevealer instead of revealing FireFox, does something very strange: it shows a small label in the top-left corner of the screen, usually with something related to the opened tab. I suspect this has to do with the Window Style and the way the ShowWindow function works in Windows 7. However, sometimes it works, showing the actual window. But most of the time it doesn't. And when it stops working, I never get it to work again until certain unknown circumstances occur and it works again. Regardless, this worked pefectly under Windows XP and does not work at all now.
If you wish to reproduce the FireFox issue, use the code I attached: instead of searching for "Hideable Application" text in FindWindow API, search for "MozillaWindowClass", install FireFox 7 or 8 and install the FireFox "Minimize To Tray Revived" addon.
I should also mention that I'm aware of the "ForegroundLockTimeout" registry setting and I have set it to 0 everywhere it appears in the Registry. On Windows XP it is set by default to 0 but in Windows 7 the default value was 200000, which I have changed. Maybe somehow it lingers somewhere??? And Visual Studio, while running, sets it to 200000 when I shut it down, until I restart the computer? I looked in the Registry and it doesn't change, it's still 0. But who knows?
I have a graphical control that is multithreaded.
Until now it worked fine, but I just noticed that whenever I'm on my application showing this control the following happens: if I lock and unlock my workstation, it freezes, like if it were in some kind of infinite loop.
Even stranger, this bug occurs only when I'm not launching the app from Visual Studio, and not attached to it.
Does anyone have a clue on what's happening?
For instance, if I attach Visual Studio to the already freezed app, can I see which lines of code my threads are executing?
Any help will be appreciated!
We recently had (for about a year and a half ;) this same problem. It also triggers sometimes when IE flushes caches, when you change colors of you theme. etc.
The problem was that we had a splash screen that had its window created on one thread and then it was shown (ShowDialog()) within other thread. Once we moved the window creation to the same thread that actually shows it, it resumed. There was also some changes with .Dispose():ng the splash window, and they could also have had an effect.
Microsoft has an article about this and they basically suggest to run their Spy++ program and look at your program when it's hung. There is a "Windows" -window, search for your application and look for any windows that should not be there. They possibly have a windows message pump active/attached but it is not pumping. The "change" message does not get handled and all .NET windows stall -> hang.
just attach VS to the frozen app and hit Pause button, VS will show executing code.
I'm having problems getting an application I wrote for Windows Mobile 6.0 to run more than one time on my smart phone.
I built it into a .cab and it installs and runs fine the first time, but if I close the application and try to start it again, it will not run unless I restart the phone.
I have checked the task manager after closing the application and it does not show up.
Are you sure that you are closing your application properly? I recommend using a process manager to see if your application still runs on the background.
My problem was in not handling closing the main Form when the application exited from one of the other forms. Ex: application starts with calculator loaded, user loads unit conversion form from calculator form, and the app hides the calculator. User then closes the unit form and calculator is still running.
All that I missed was handling an OnClosed event in my main form for when the user tried closing the application from one of the other forms.