Ok this question stems from this question:
wp7: App failing! Can not figure out where?
I thought it was corrected but it is still failing. I ripped out all of the app.xaml.cs code and it still crashing when the search button is clicked and the back button is immediately pressed.
So... I decided to see if I could replicate the issue with a new test app. Basically I have create a basic pivot application with the default Main View Model. None of my code exists...
I press the search button and then immediately press the back button and low and behold... The SAME THING HAPPENS.... It crashes the application, the emulator shows a blank screen and the debugger stops!
So... That leads me to believe that I've found a bug in the emulator (I find this very hard to believe)... OR, my Studio environment maybe is corrupted (I'm hoping it is not).
I'm not sure where to go on this one. I don't know what the error is, and it is preventing my apps from being accepted on the market place.
Does anyone have any ideas?
I made a screen capture of what I'm seeing:
Notice that the 1st 3 search/back combos work as the boxes in the search screen are allowed to display. However, the last 2 search/back combos don't work as you will see that the boxes aren't allowed to display...
http://www.youtube.com/watch?v=XVht3OtBGaI
The error report I'm getting from Microsoft:
Comments: The application reactivate after deactivation and terminates unexpectedly.
Steps to reproduce:
1) Launch the application.
2) Select a vehicle.
3) Press the device's "Start" button.
4) Select the device's "Back" button.
5) Observe the application terminates unexpectedly and does not reactive the application.
This error is reproducible 8 out of 10 times.
The other error report from a different application:
Comments: The application terminates rather than resuming when the user attempts to return from a Search.
Steps to reproduce:
1. Launch the application
2. Select the Add + button
3. Press the Search button
4. Press the Back button
5. Observe the application terminates after a few seconds.
I noticed that:
When the following happens in the debugger:
The thread '<No Name>' (0xd1b0092) has exited with code 0 (0x0).
The thread '<No Name>' (0xd6900ba) has exited with code 0 (0x0).
That the project DOES NOT FAIL as described (100% of the time). However, if I click the back button before this, then the application fails (100% of the time).
Update #1: App.xaml.cs
// Code to execute when the application is launching (eg, from Start)
// This code will not execute when the application is reactivated
private void Application_Launching(object sender, LaunchingEventArgs e)
{
}
// Code to execute when the application is activated (brought to foreground)
// This code will not execute when the application is first launched
private void Application_Activated(object sender, ActivatedEventArgs e)
{
// Ensure that application state is restored appropriately
if (!App.ViewModel.IsDataLoaded)
{
App.ViewModel.LoadData();
}
}
// Code to execute when the application is deactivated (sent to background)
// This code will not execute when the application is closing
private void Application_Deactivated(object sender, DeactivatedEventArgs e)
{
}
// Code to execute when the application is closing (eg, user hit Back)
// This code will not execute when the application is deactivated
private void Application_Closing(object sender, ClosingEventArgs e)
{
// Ensure that required application state is persisted here.
}
OK, after hours of banging my head against my desk I have found that the emulator on some machines are having the same issue I am seeing.
So... The 1st thing I did was to wrap all my functions in Try/Catch blocks... Even the smallest functions and the ones that can't error. Then I side loaded the application to see if I can get it to crash. When I felt I sufficiently tested it on my phone I re-submitted the app. In the testing notes section I asked for them to test it on a device rather than an emulator. I never heard if they did this or not, but they passed my app, so I'm guessing that they did.
Thanks to #Praetorian and #Matt Lacey and #willmel and anyone else that took a look at this problem for me. I appreciate it!
I also noticed that If you create an new wp7 application this also happend.
Create a new application. Start it.
When it has started press the Start button and immidiately click the back button. It now says Resuming.. but nothing happens.
When you try to restart the app you only get to the splashscreen.
But I found out that if you build the app using Build=Release and dont debug the app (run it on a device) this does not occur..
Can you check if this is the case for you as well.. If so them im also in trouble
Related
I'm creating an app using WinUI3 (UNO actually, but I don't think this is relevant) to babysit an application written in 2007 that I have no control over. I'm starting it like this:
try
{
using var process = Process.Start("child.exe");
await process.WaitForExitAsync();
//...do some processing here
}
catch (Exception)
{
throw; //only here so that I can set a breakpoint to debug this issue
}
Peculiarly, when the child.exe exits it takes down the parent app with it. This is not the default behavior since starting other programs the same way do not do this. Things I have already looked into:
The catch block never catches anything. The same thing happens even if I comment out the await line and everything after.
Breakpoints after the try block are not hit. Visual Studio debugger simply detaches from the parent app.
Event Viewer does not log any error events related to this.
Attaching spy++ to the parent app shows that WM_Close isn't being sent to it. In fact, the moment the child terminates spy++ logs no more messages from the parent at all. (If I close the parent app normally then spy++ does log window messages associated with closing)
Overriding App.Closed event and setting WindowEventArgs.Handled = true does not prevent the parent from dying. (The close button is disabled as expected, so the event is working fine)
At this point I'm pretty sure the child.exe is actively doing something to kill the parent, although running the program directly doesn't seem to do the same thing to explorer. While I'm curious about what it could be doing to cause this, I'm more interested in ways to prevent my parent app from dying.
I noticed something strange with my Xamarin application.
First in Xamarin: Running the Application was fine until I click the upper right X to close the App. In Xamarin the button on the left is still a red square and I can "stop the current startup project".
Second: after packing up the application (7zip) and starting it out of the archive, after closing the app, 7zip told me to stop the application before it is able to close the archive.
Is there anything i'm missing here? Do i have to setup anything to shutdown the App properly?
there even is a OnDeleteEvent
protected void OnDeleteEvent(object sender, DeleteEventArgs a)
{
Application.Quit();
a.RetVal = true;
}
but with a breakpoint there, it seems not to be used when clicking the X-Button.
Note: I'm using the GTK#2.0 Project template with Xamarin 6.2
i had to add the line
this.DeleteEvent += new global::Gtk.DeleteEventHandler(this.OnDeleteEvent);
into the sourcecode of my MainWindow. Somehow this line was missing.
It's working as intended now.
I saw this problem in several places on the internet, without any clear solution. I do need support to know how to detect the root cause and fix this problem for ever.
A ClickOnce application published and works on almost all computers, crashes after loading the startup form without any errors.
Crashes means -
'Verifying application requirements' dialog box checks latest updates perfectly. In case there is, it downloads automatically.
Startup form opens for maximum 1 second, then closes automatically. [frequently] OR
Startup form opens, user types a letter (or clicks the mouse), then app closes automatically. [rarely]
No error message is thrown.
This phenomenon happens only on a limited number of computers, under specific user profiles. This means that on the same computer, the app launches without problem for user 'A', while for another user it crashes.
Already tried the following, without any solution -
Uninstall/reinstall the app - in most of the cases it works, but not always. Furthermore, it sometimes crashes when publishing new updates, on computers where the app was previously working.
Certificates - publishing the app with or without certificate does not make any difference.
Delete/Create user profile - did not solve the problem.
Manually delete the user profile folder from Documents And Settings/[user]/...
No Kensington mouse driver is avaliable on the computers.
Try/Catch blocks in Program.cs or in Startup form InitializeComponents()
Any idea where the problem is coming from, and how it can be detected?
Here is the code for Program.cs
namespace NCR_MaterialToolbox
{
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException);
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new frmLogin());
}
}
}
Here is the code for frmLogin
public frmLogin()
{
InitializeComponent();
}
I'm using WinLIRC with IR receiver connected to serial port COM1 on Windows 7 x64. WinLIRC is added to Startup folder (Start->All applications->Startup) so it starts every time I log in. Very often (but not all the time) I see initialization error messages from WinLIRC, which continue for some time (couple of minutes) if I retry initialization, and after some retries it initializes correctly and works fine. If I remove it from Startup and start manually at any other moment it starts without errors.
I've downloaded WinLIRC sources and added MessageBox calls here and there so I can see what happens during initialization and found out that CreateFile call fails:
if((hPort=CreateFile(
settings.port,GENERIC_READ | GENERIC_WRITE,
0,0,OPEN_EXISTING,FILE_FLAG_OVERLAPPED,0))==INVALID_HANDLE_VALUE)
{
char buffer[256];
sprintf_s(buffer, "CreateFile(%s) failed with %d", settings.port, GetLastError());
MessageBox(NULL, buffer, "debug", MB_OK);
hPort=NULL;
return false;
}
I see message box saying "CreateFile(COM1) failed with 5", and 5 is an error code for "Access denied" error according to this link.
So the question is why opening COM-port can fail with such error right after booting Windows and proceed normally few seconds or minutes later?
Update: the COM-port is the real one.
Update2: regarding the other application that opens serial port before WinLIRC. I did the following: I put Process Explorer to the Startup folder so it start on log in also, then rebooted. As soon as process explorer started I ran "Find Handle or Dll" dialog, put "Serial0" to the input and hit "Search". By that moment WinLIRC had already shown message box saying "CreateFile(COM1) failed with 5". Then I waited till the process explorer search ends, seen that it found nothing, then tried to reinitialize WinLIRC and it failed again. So I suggest that it is not the case of serial port being opened by other application. If anyone can suggest a better way to check it, I'll happily recheck.
When I search for "Serial0" in process explorer while WinLIRC is running it finds the winlirc.exe process, so it looks like it is correct term to search.
Update3: regarding the serial mouse driver. It is not listed in device manager, so I wasn't able to disable it there, however I have found this instructions on how to disable sermouse service and it didn't help.
Update4: one more thing I forgot to mention. It happens only if I log in soon after booting PC. If I leave windows on log in screen for several minutes and log in later, then WinLIRC initializes without any problems always.
Update5: Unfortunately, I don't have access to the computer that had this problem reproducing, so I can't experiment anymore.
It takes time to initialize the port.
Your application will run absolutely fine on windows XP.
Windows7's serial ports are virtual.
You can run a small code and check it out
using System.IO.Ports;
private void Form1_Load(object sender, EventArgs e)
{
string[] ports = System.IO.Ports.SerialPort.GetPortNames();
comboBox1.Items.Add("None");
foreach (string port in ports)
comboBox1.Items.Add(port);
comboBox1.SelectedIndex = 0;
}
This will return you the list of serial port. Check the status of it and display it on message box.
Make this code and run at startup. You'll get the root cause.
Here some links one has to visit before plunging into the magic world of serial programming in Windows :)
A detailed explanation of serial programming in Windows:
http://www.codeguru.com/cpp/i-n/network/serialcommunications/article.php/c5425/Serial-Communication-in-Windows.htm
a little bit outdated (the site states 1999-2003 so yes, it's outdated) but absolutely useful:
http://www.flounder.com/serial.htm
I'm trying to add support for tracking application usage to a WP7 app (e.g., how many times has the app been run, including wakeups from tombstoning). I thought I was doing this in a pretty straight-forward way, but I'm frequently getting IsolatedStorageExceptions, and I'm kind of at a loss for debugging it at the moment.
Paraphrasing from my App.xaml.cs
private void HandleAppCounter() {
int i = 0;
settings.TryGetValue<int>("usage", out i);
i++;
settings["usage"] = i;
settings.Save();
}
I call this function when the app is launching or activating. The thing is, it works just fine. But the thing is, if I make another call to isolated storage soon after then that is what blows up. And furthermore, it seems to only blow up if the next call happens pretty soon after.. although I'm having trouble understanding that as well.
The next action performed is usually a user clicking an item in a list. If it happens immediately when it's displayed, I get a crash from isolated storage. If the user waits a few seconds after the app is launched and then clicks it, there is no crash.
If the above code in HandleAppCounter() is commented out, then the user can click either immediately or later and it never crashes.
Can anyone give me some tips on how to debug this? I'm kind of running into a wall here.
I would suggest stepping away from your custom implementation for a sec and try the same behaviour with the default IsolatedStorageSettings class, if it is still a problem then you should report it to Microsoft Connect site as a bug, otherwise there is some kind of an error in your settings class.
If you're using IsolatedStorageSettings you might want to make sure, that whenever you're querying/adding a key, the key is there, if not you must create it.
If you're using IsolatedStorage filesystem then make sure you are always closing the streams when you're reading/writing. If you don't you will get absurd exceptions.