There is a random bug as mentioned below which says something wrong while setting the SystemTray visibility. I have set the SystemTray visibility to false in xaml. It randomly crashes the app sometimes and not always. The exception thrown is System.ArgumentException Value does not fall within the expected range.
The stacktrace is as below
Microsoft.Phone.Shell.Interop.NativeSystemTrayMethods.SetSysTrayVisible(IntPtr pSysTray, Boolean fVisible)
Microsoft.Phone.Shell.Interop.NativeSystemTrayInteropWrapper.SetSystemTrayVisible(Boolean isVisible)
Microsoft.Phone.Controls.PhoneApplicationPage.set_SystemTrayIsVisible(Boolean value)
Microsoft.Phone.Controls.PhoneApplicationPage..ctor()
What can be the probable reason for it? Any workarounds? Any leads are appreciated.
This is not a solution in any way.
We are seeing the same error mostly (90%) on WP8.0 devices and there is a very very small percentage of WP8.1 devices. Other error reports do not contain version of the OS for some reason.
Here is what we found out with advanced technical support from Microsoft.
This is a known problem that was fixed for WP8.1.
I looked at the SetSystemTrayVisible bug that stack trace suggests and confirmed should be fixed in WP8.1.
I’m not sure why you’re seeing some instances on 8.10.14234, but there may be a second, rarer, issue in that area
Unfortunately, there isn’t anything you can do in your code to prevent this on WP8.0. The problem occurs in the root page initialization where it’s setting the default state of the system tray. There’s an incorrect guard check in native interop, so if a handle gets initialized to a bad value the exception is raised. The guard was fixed for WP8.1
You should be able to detect the error ... expect it to trigger the Application_UnhandledException handler from which you can display a message box.
So the best way to handle that exception is to just catch it (detect) and then suggest user to upgrade the OS to WP8.1.
I am not sure how feasible is that cause we were unable to reproduce this error on our devices or emulators.
Hope this helps!
Make sure you have all the .dll's loaded into Visual Studio!
also make sure you wrote the string all the way to the top of the page.xaml.cs
using Microsoft.Phone.Shell;
I have already done that and it works like a charm for me!
//Fullscreen mode.
SystemTray.IsVisible = false;
Regards! //Bachir Bouchemla
Related
I create a sipphone using CefSharp and WPF. Until some time everything worked, but today I got the error "TrackStartError", although I did not change anything in the code. I checked to see if this works in "CefSharp.MinimalExample.Wpf" and it does not work there either. However, in the browser Chrome still works.
For verification, I performed in the console CefSharp Devtools:
enter image description here
In this question it is said that "at the level of the operating system, browser or web page, there was a hardware error that prevented access to the device." What could be the reason for this? And how to fix it?
If this is due to the fact that some application has seized control of the microphone, how I can determine this application?
P.S. Sorry for my bad English
I found the source of the problem. In my case, the microphone was blocked by an antivirus (Kaspersky endpoint security).After disabling it, the error disappeared.
I was in the middle of developing an update to my Xamarin Forms app, but when I debugged it on my iPhone, it crashed immediately on startup with the following message:
Assertion failure in -[UIApplication_runWithMainScene:transitionContext:completion:], /BuildRoot/Library/Caches/com/apple.xbs/Source/UIKit/UIKit-3600.5.2/UIApplication.m:3679
It was previously working fine, but now I can't run the app on my phone anymore without this crash. I have rebuilt several times and deployed from different computers, but nothing helps. How do I fix this issue?
Edit:
Before this started occurring, I had made some additions to the code. Unfortunately, after removing all of my changes, this issue is still plaguing further development. Any help or resource that might lead me to a solution will be greatly appreciated.
After some deep searching, it turns out that I mistakenly removed a part of my Application's constructor that initialized the MainPage. As a result, MainPage remained null. The framework probably tried to call a method or access a property without checking if the reference was null, causing the error. I'm not sure how long that mistake has been there.
This can also happen if you are not quick to launch a view. Avoid calling APIs or other lengthy processes before a page is displayed for the first time. You may do that in parallel but not in the same thread that launches the page.
We are currently trying to incorporate Lync communication (Lync SDK 2010) into our application and we have run into an issue with the VideoWindows (CaptureVideoWindow, RenderVideoWindow) of the AVModality's VideoChannel: They are always null, even after successfully calling BeginStart. The connection is definitely established. We can talk. Our own video is shown in a remote Lync client. AVModalityState is Connected. VideoChannelState goes from Connecting to Receive to Send.
It does not matter when and how we try to access them: Directly after BeginStart, in the AsyncCallback of BeginStart, in response to various state changes or in response to an external trigger (user click event); in the main/UI thread or in an event/callback thread. The two video windows are always null.
In the example application "%PROGRAMFILES%\Microsoft Lync\SDK\Samples\AudioVideoConversation", everything works as intended: As soon as BeginStart has finished, we can access the non-null video windows. In our little stand-alone prototype project, it works, too. But in our real application, it does not.
We have double checked everything and we have really run out of ideas of what might cause this problem.
Any ideas, any hints? Anything that we should be aware of?
(Link to corresponding MSDN forum thread)
Update (4th July 2012, 15:46 CET):
When we take a look at the members of the VideoChannel we find that internally a COMException occured in "Microsoft.Office.Uc": Error loading DLL, HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY). More details in the attached screenshot.
We did some research on this error, but found nothing that worked for us. Any ideas what causes the Exception?
Update (9th July 2012, 16:43 CET):
We did some further testing...
Our software consists of one main application and many plugin-like "apps" loaded via MEF. We created a minimal test app that makes a video call: The video windows did not work (as expected). But when we took the identical code and created a separate solution outside of our architecture, then it did work. So, it was an issue with the environment, not the code.
At first, we suspected MEF might be the problem. So, we hacked the lync code into our main application - circumventing the whole app architecture. Still not working.
Then we sliced off our whole system, bit by bit, until we finally reached a point where it did work. After following wrong tracks several times, we finally found the culprit... Quartz.NET!
For some strange reason the mere presence of an assembly reference to the Quartz.dll v.1.0.3.3, even without a single line of Quartz code, causes the video windows to not work. Unbelievable, but it's 100% reproducible: If we take the previously mentioned test solution and do nothing but add the reference, it stops working.
Any idea how such a thing is possible?
We solved it! Kind of. A reference to a Quartz.NET DLL somehow caused the issue. More details in the updated question.
For now, we have removed the component that used Quartz. We currently do not need it.
But I'm still interested in further input how a mere reference can cause such an issue.
I'm building a Windows Forms application in C#, and testing on Windows 7 64bit revealed a silent crash.
The exact line that it fails on is this.ResumeLayout(false); near the end of the InitializeComponent() function. It's a part of the Visual Studio generated code from the Forms Designer.
There is no exception, no popup to show the program has crashed, nothing. It simply ceases to run once it hits that line. This only occurs in 64bit. Removing that line, the program runs, but cannot be maximized, and there are several other oddities related to window properties.
I've tried everything from changing build settings to using CorFlags.exe, nothing has helped. What could be the issue?
If it makes a difference, I'm using OpenTK and the GL Controls.
Had an identical problem, only in my case the software ran on some 64-bit systems and not others. For example, my laptop is a vaio pcg series bought just this year. 64-bit Windows 7 Home Edition, 1600 x 900 resolution. Program runs just fine here. My colleague has a vaio svz series, 64-bit Windows Professional with 1920 x 1080 resolution, and for some reason his kept getting the silent crash on the ResumeLayout(false) call.
Again, commenting out the this->SuspendLayout() call near the top of the INitializeComponents() sub, and the this->ResumeLayout(false) call near the bottom fixed the problem, and the program seems to run fine on both systems now.
I had the same exact problem with ResumeLayout(). It ran fine on several machines, but I had one user who had it throwing "Exception has been thrown by the target of an invocation." Not very helpful. Unfortunately they also hide some of the details from Exception.StackTrace. I consulted with our resident expert and he felt it was a resizing issue. I discovered exactly where the problem was after going to DEBUG-->Exceptions and selecting everything. I then got a break right inside a function I was using to reposition some checkboxes. For some reason this was throwing an out of range exception on this user's box...
Rectangle rect = dataGridView.GetCellDisplayRectangle(col, row, true);
The point being that selecting the break on exceptions options as I described helped me pinpoint the actual problem. The workaround that others mentioned is fine, but in this case I was able to find the root cause.
Do you use some external component?
Some OCX which is not compatible with 64bit? I had your same trouble using GdPicture.
If so, try to compile for 32bit and problem could be solved.
A simple solution to this whole ordeal was to simply remove both the offending ResumeLayout() call and its corresponding SuspendLayout() call at the beginning of the InitializeComponent() function. It seems to have had no ill effect on the layout of the window despite having a heavy number of controls on the window. Again, this was only for 64 bit machines, the issue never popped up on Windows XP or 7 32 bit.
I'm still baffled as to why the ResumeLayout() call was causing a silent crash in the first place, and still feel slightly uneasy about the "solution", but it seems to have worked.
I have a piece of software that has worked fine on many machines, althoughon one machine there is a problem that appears to occur occasionaly, the MenuStrip and the ToolStrip both appear as a blank white background with a red cross over it, as a custom control would if you created a null object. This doesn't happen whilst I am debugging and I don't know how to make the problem re-occur, but it does happen. I was wondering if anyone knew what could be the problem?
Would it be the version of the .NET framework?
Thanks
This is a common occurrence when there's a GDI+ problem ("The Red X of Death"). Are you doing any custom drawing in OnPaint? Or perhaps there's a graphic resource or a glyph which is corrupt or being improperly disposed of.
Edit: I've re-read your question. You seem to have this only on one of the machines. I've googled around a bit for this, and I stumbled upon this old thread. The post at the bottom suggests that there might be an issue with Virtual Memory turned off:
We did manage to solve this - we were
seeing the problem on a device running
XP embedded. The XPe image developer
had turned off Virtual Memory and as
soon as we turned it on the problem
went away. I believe it is just a
symptom of the system running out of
memory to display the graphics (maybe
particularly if you use a lot of
double buffering)
Hope that helps.
Sounds like a symptom of an Out Of Memory Exception to me.
Edit:
Which can sometimes lead onto a System.InvalidOperationException: BufferedGraphicsContext
Are you trying to update the GUI controls from a thread other than the GUI thread? Combine the cross thread operation with an exception handler that swallowed everything and we had the behavior you describe (on a grid control, not a menustrip bar) on an app I was maintaining.
Definitively sounds like a cross-thread problem.
Make sure you use Invoke when accessing controls and/or firing events from a thread that is not the main UI thread.
Seeing this happen on just one computer of more than a 1000 that have our prouducts.
On that one computer I am seeing a .NET 3.5 program occassionally show the red X on its datagrid. And another far simpler .NET 2.0 program got the red X on its menuStrip. I only have source code for the simpler program but I can say that there isn't any user code at all which affects that component. No cross-thread stuff because nothing updates it. It's contents are set at development time with one item added to it at program load. The Red X failure was well after program load.
I was very surprised to see the problem across two different frameworks and on one program that has no data bindings. I am very wishfully hoping that the computer has its virtual memory turned off.
If it isn't that then any guidance on system parts that are shared across .NET 2.0 and .NET 3.5 would be appreciated.
Update: The user with the problem retired the computer and replaced it (which solved the problem)