My app builds fine. Attempting to start it in debug mode, however, causes this error. This appeared after I solved an error relating to missing "debug symbols" similar to the one here (enabling the remote symbol servers in the options and then building caused this error to appear instead - this behavior persisted even after turning off the remote symbol servers in the options again).
I am using WinUI3 project on Visual Studio 2022 on Windows 11.
This post seems to suggest the issue was using WPF - but I am not using WPF. I also see a potentially similar issue here, but there appear to be no answers.
I am not sure where to even begin fixing this - it seems to be a Visual Studio issue or a project/solution config issue rather than a code issue. Any ideas?
I fixed it. I was looking at the output in the Visual Studio Console (after stopping the app once the error mentioned in the question happened), and I saw this:
Exception thrown at 0x00007FFD41D4466C (KernelBase.dll) in EmailClient.exe: WinRT originate error - 0x80004005 : 'WinUI: Error creating second Desktop Window on the current process. No more than one Desktop Window is allowed per process.'. onecore\com\combase\winrt\error\restrictederror.cpp(1017)\combase.dll!00007FFD43EAA21E: (caller: 00007FFD43D9A2F3) ReturnHr(2) tid(5e98) 8007007E The specified module could not be found.
I then searched through my project, and found out I was calling new MainWindow() one place in my project outside of the App.xaml.cs when initializing a property. I removed that (initializing the property to null instead), and now the app works fine. Not sure how the two are related... but this may be an unexpected behavior caused by attempting to create multiple windows on the same process. Here is someone else who had the same issue.
If your intention is to create multiple windows (mine was not) and you want to know how, then see this thread (a few months out-of-date... not sure if the mentioned features are still in preview or not as of time of posting).
Related
I am attempting to debug a custom plugin that was developed so that I can track down some errors that is causing ArcGIS to crash.
My problem is that whenever I set up a breakpoint I get "No symbols have been loaded for this document"
So I tried placing in a Stop point so I can step through after a known event e.g. Mouse click
Still ArcGIS crashes and the debug halts entirely.
It almost seems that ArcGIS has just loaded the program in and isn't returning anything back to Visual Studio.
Any insight on this would be greatly appreciated.
-UPDATE
I think it may have something to do with the API as it will still run once the debugger has stopped.
Try to “clean solution” and “rebuild solution”.
"No symbols have been loaded for this document" message shows that your current code does not used in running application.
Using the WebView control in the Windows 8 SDK Samples results in an unhandled 'Unspecified error'.
In my own project it gives me an unhandled exception of 'Unable to get property '1' of undefined or null reference'.
I can't catch it.
It doesn't happen if I deploy it to a Surface or on another machine so I think it's probably my machine.
I need to know what I can do to fix this issue on my machine.
Any help appreciated.
When you debug a XAML app with a WebView whose content has a JavaScript exception, that exception is elevated up through the WebView to Visual Studio where you (presumably) can debug it. When you run this (CTRL+F5) without debugging, these types of errors are swallowed. So your experience is not your machine, but the fact that the debugger is attached.
You can find a similar question and its answer here: https://stackoverflow.com/a/12249831/265706 But beware that the answer to that question suggests disabling the debugging mechanism. Make sure that is what you really want to do.
Can anyone help for the following ERROR:
Couldn't register com.india.XXX with the bootstrap server. Error: unknown error code.
This generally means that another instance of this process was already running or is hung in the debugger.
here m using xcode 4.1 and i have same project folders in my local desk.
When ever i open multiple projects with the same name its showing the above error.
Thanks in advance.
Some of the fixes that the links Saif contain may work for some, but not for me.
I have a very simple solution without restarting that will usually get you through the day.
When you get this error, before you do anything else, build for the other device (if you are running a universal application).
When you build for the other device, it kind of "overwrites" the process that creates this error. Once the other device is up and running, immediately build for the device that created the error. This will work most if not all the time, and will save you time digging through the multitude of fixes you will find in the other links.
I tried almost all of the fixes found there and none of them worked in my case. This works, but you should check your appDelegate for any bugs in your willEnter/didEnter (and other related methods).
I'm converting all of my Windows XP production applications to Windows 7 and I am having a couple of problems.
1: Whenever I get an error, on the XP machines, it breaks execution and stops on the line of code with the problem. In Windows 7, it just throws a generic exception and I have no idea where the line of code with the error took place. Very frustrating.
2: In XP, I can edit changes on the fly while I am running code if I place breakpoints or follow along the code. If I try that in Windows 7, it says that's not allowed with 64 bit applications. Again, very frustrating.
Any ideas for fixing these problems or at least working around them?
There shouldn't be any difference in the debugger's behavior between those two platforms, generally speaking. Here are my suggestions:
From your description, I can't ascertain whether or not the debugger did break on a first chance exception and it didn't find source (perhaps the symbols weren't found / were mismatched?) or if it didn't break at all. If the former, check "Debug -> Windows -> Modules" and verify that the symbols were loaded for the module in question. If the latter, perhaps the debugger on Windows XP was configured to break on a first chance exception while the debugger on Windows 7 was not? Compare the settings under "Debug -> Exceptions" to see if there are any differences. Note that if you have "Just My Code" enabled in "Tools -> Options -> Debugging -> General", this can also affect the breaking behavior of the debugger on first chance exceptions.
The Edit and Continue feature is not supported for 64-bit processes, so the debugger will notify you when you attempt to modify the source code when debugging a 64-bit process. This is likely the result of running an "AnyCPU" (my guess) or "x64" build of your application. The only way for edit and continue to work is to debug a 32-bit process; this can be accomplished by changing the target platform to "x86" in "Build -> Configuration Manager" (add the platform if it isn't in the list). This of course assumes your application is not dependent upon 64-bit modules.
Do you know roughly where the error is coming from? If so, and not already done, throw a generic try catch around it and break on the catch; then, examine the stack trace to see what line is generating the error.
Hope this helps.
I was part of a team that developed a Surface application during the summer. I was set to do some minor changes to this application now, but got errors that were not present last time the exact same code was ran.
The error message is "GeometryHitTestParameters' HitTestParameters are not supported on 'Viewport3DVisual" and is complaining about some parameter in theVisualTreeHelper. HitTest().
The code is the same, but the working environment is slightly different:
I could not find the old SDK, so i had to use Surface SDK 1.0 SP1.
The computer is running Windows 7
I've got the code running by catching all exceptions and ignoring them.
Does anyone know if Surface SDK SP1 could have changed the way 'Viewport3DVisual is used or if the SDK is throwing exceptions not thrown in 1.0?
I would really like to know if masking this exception will make the application run like it used to or if the changes in behavior would turn up later and backfire.
I've had the same exception myself. We were unable to resolve it and just shipped with the defect. I'm pretty sure its a bug in the SDK.