After updating to the 7.1 SDK, my app will sometimes (appears to be random) crash to the home screen immediately after launching. This happens on the simulator and the device. I haven't been able to reproduce this at all on the 7.0.3 SDK. When debugging on the device, there are no error messages received when this happens. The app will crash to the home screen and the last line in the Application Output on Xamarin will read:
Launching /private/var/mobile/Applications/7840DFD4-9B41-4DA5-86FB-CBBF37A03BB2/MyApp.app -debugtrack -monodevelop-port 10000 -connection-mode usb
On the device, if I try to launch the app again by tapping the icon, it will keep crashing out to the home screen. However, if I delete the app and re-deploy it will usually work and then I can open and close the app without any crashes. On the simulator, after the initial app crash I can relaunch the app by tapping the icon on the home screen and it will work without issue.
I've checked the System Log after a crash and compared it to the System Log with no crash. The only difference is the following four lines:
SpringBoard[8050] <Warning>: LICreateIconForImage passed NULL CGImageRef image
SpringBoard[8050] <Warning>: SMS Plugin initialized.
SpringBoard[8050] <Warning>: Sharing Plugin initialized.
SpringBoard[8050] <Warning>: SIMToolkit plugin for SpringBoard initialized.
These lines don't show up at all during a successful launch, but will show up every single time I get the immediate crash described above. I'm really having a difficult time tracking down the reason for this, as like I said it only happens on 7.1. Any help would be much appreciated.
Thank you.
Related
I have a fairly large project on Unity 2018.4.2 that is failing in two places when I build: connecting to the user's microphone and opening the Finder window. Opening Finder takes up to 30 seconds to actually open it and microphone hangs whenever I try to start it.
We use the code below to open the Finder Window
System.Diagnostics.Process p = System.Diagnostics.Process.Start("open", $"\"{macPath}\"");
It eventually opens the Finder window, but only after 10-30 seconds. Meanwhile, a MacOS process called "tccd" kicks in causing the CPU to spike.
For Microphone, we use Unity's built-in Microphone class and we get hangs that last for 15-50 seconds. Same thing happens where the "tccd" process kicks in and spikes our CPU.
When we try to connect to the microphone the first time the OS asks us once if we want to allow the app to access the microphone, but it always hangs even after confirming. It never asks us about accessing Finder.
It seems like the MacOS is actively trying to slow us down from accessing these, but not completely stopping us, as Finder eventually opens and the microphone eventually connects (sometimes). We do not have these problems on Windows, it's only on MacOS. Any thoughts as to what is happening?
Note: There are no problems in Editor, only in Mac builds
We found the problem. Our code had to be signed in order to use it on a Mac. Now that the app is signed, we have access to everything we need as listed in our entitlements file
I'm dealing with a strange issue that's been giving me headaches for a long time.
I've got a Windows Phone 8.1 (WinRT) app, whose first version I published a couple of years ago. Over the last few months, I've been working on a major update which includes augmented reality as the most prominent feature.
Obviously, the app needs to make use of the camera preview, and that's where trouble starts. I've read discussions in other threads about problems with the camera API, but I didn't find a definite solution.
Before submitting the update, I performed extensive tests on my Lumia 620 and all worked fine. But if the app is downloaded from the store, it crashes and the camera picture goes green as soon as the camera preview starts. It is the very same app package and all required capabilites have been declared.
So basically I can't tell if my app works or not, unless I submit it to the store.
Any help will be appreciated.
Edit: After several hidden-app submissions, I've narrowed down the cause of the crash to the following block of code:
RandomAccessStreamReference rasr = RandomAccessStreamReference.CreateFromUri(new Uri("ms-appx:///Assets/Square44x44Logo.scale-100.png"));
var streamWithContent = await rasr.OpenReadAsync();
The last of the above lines causes the app to terminate. The same code works fine when the app is deployed from VS.
Any ideas?
It looks like the problem is now resolved. The cause of the crashes was the asset file. This file is a scaled version of the app tile, which is created automatically by Visual Studio. Using this file is allowed when the app is deployed from VS, but not in the store.
We have a C# tool (that I wrote) that records online broadcasts taking place a custom written (that we wrote) flash app. (There are no DRM or copyright issues here.)
We've coded up a system whereby this tool is installed on a Windows Server 2012 R2 Amazon AWS instance. After we boot the instance, the tool loads, waits for the right time to start recording, launches a browser and passes the command line argument of the URL to access the broadcast. The browser will then load the flash app and the interview audio and video will start arriving at the browser instance on AWS
By way of a virtual audio cable driver, screen / audio capture directshow filters and ffmpeg a screen recording is taken. The C# tool calls ffmpeg and ffmpeg will record the screen reliably for the entire interview, then the tool shuts the whole thing down
The problem I'm having is that both Chrome and Electron browser sometimes simply don't draw themselves on the screen so all ffmpeg ends up recording is a blank desktop and the audio of the broadcast (hence, the browser IS running)
We found this out when recordings started turning up with X hours of merely recording the windows desktop and the tool's main window with a countdown timer.
A screenshotting facility was built into the tool and added to its web control interface, and this way we can test whether the browser is visible - a human looks at the screenshot of every broadcast, just after recording has started (the browser is supposed to be on show by this time)
We notice that 50% of the time, the browser isn't drawing itself on screen. By 50% I mean that every other recording that the AWS instance carries out, will be blank: AWS starts, records ok, shuts down. AWS starts again an hour later for a different broadcast, recording is blank, shuts down.. Starts/ok/shutdown. Starts/blank/shutdown. Repeat ad infinitum
What's even more strange is that if I run VNCviewer on my dev machine and connect up to an instance that is having a problem, the instant that the VNC connection is up and the remote desktop is showing on my screen, the browser suddenly appears as if nothing was ever wrong. A screenshot from before the VNC connect shows blank desktop, connect VNC, take another screenshot and the browser is there. All through it the audio is fine - the browser connected to the boadcast is fine, for sure
It's as though Chrome/Electron thinks "you know what, noone is looking at me so I'm not going to bother drawing myself". No screen saver is set, though the power plan has the setting "turn off the display after 15 minutes".
Perhaps Chrome/Electron have a test amounts to "if the display is off, don't draw". I can't explain the inconsistency though - the recorder launches at least 1 hour before it's needed, and sits there idle until it's time to start the browser. You'd hence imagine that the "power off the monitor after 15 mins" setting would reliably have ensured the "monitor" is "off" by the time every recording start comes around
This behaviour doesn't happen with any of the other browsers (but unfortunately the app doesn't and cannot work in them because it uses some weird chrome-only technology/API).
Can anyone suggest anything to look at to help debug this, or anything I can build into the C# tool to overcome the problem? Coding it up to connect to itself via VNC for a few seconds after it has launched the browser.. Well that just tastes nasty.
Naturally, as soon as I connect to the machine via VNC (rather than RDP - RDP isn't usable because the recording context is in a logged on session for a particular user) the problem goes away, which makes it frustratingly hard to debug.
I am not sure what exactly causes your problem, but it sounds like interacting wit the system prevents it. One way to interact with a system is to use the keyboard and this can be automated.
You could try sending a keystroke (like "F15") evey so many seconds in C# using
Windows Input Simulator or maybe SendKeys.Send and
Combine the above with some kind of Timer
Maybe take a quick peek at this app called Caffeine...it presses the "F15" key for you every so many seconds. They claim "F15" generally doesnt trigger anything in windows (since a release they made back in 2010).
Caffeine App
I am currently developing an app that seems to hang my Windows Phone 7 phone. If I start the application and then press the home button or use the back arrow and then repeat this several times then the phone actually hangs in the middle of the app start animation and I need to restart the phone.
To troubleshoot this issue I created a new project and removed all my code and put there my xaml and animations only. My xaml with the animations inside are about 2800 lines long. When used under debugger no exceptions are thrown nor any other error messages are shown.
I created a project for demonstrating my issue. Here are the steps to reproduce the problem
Open the project in Visual Studio
Select Windows Phone 7 Device
Run the application.
Start using the home or the back button to quit the app and then relaunch it again and again.
Repro_Crash - This is the project that I am using to reproduce my issue.
Image of the Crash - from this point I am forced to restart the phone.
I am looking for hints or tips regarding how to figure out what is happening!
I've tried your project and it runs perfectly fine on my HTC HD7 NoDo. It displays only a large wall of letters without any animations and does not crash the phone. I'm using the latest Mango Beta 2 Refresh SDK.
I am developing a WPF application and have recently started testing it on a machine with Windows XP Tablet edition. The application runs Full screen. When the computer goes into standby while my application is still running, returning from standby causes the igxprd32 display driver to stop working. When this happens I get a "Windows - Display Driver Stopped Responding" message, the resolution drops, and the colors get all messed up.
Instead of waiting for the computer to go into standby on it's own I've also test manually putting it into standby via the start menu. Bring the computer out of standby after this usually results in Windows crashing with a blue screen.
This only seems to happen on Windows XP Tablet edition.
What is causing this and how can I fix it?
EDIT: Apparently what I was told was wrong. The machine actually is running XP Professional,
using the Mobile Intel 945 Chipset Family. I installed the latest drivers from the Intel website, this didn't fix the problem. I did find that if you google "igxprd32" you find there are many people who have problems with this driver.
This might be too obvious but, have you checked for a more up-to-date driver? I've seen this as the answer to similar problems on the MSDN WPF forum.