I have been working with marmalade for some weeks. But since today my simulator is not working anymore. I always get "error: Couldn't initialize Direct Draw" when i launch the simulator.
I tried uninstalling marmalade and restarting pc but nothing is helping.
Anyone has an idea what this can be, or things I can try?
Error message can be seen:
PC specs if this might help:
- Acer Aspire notebook
- Windows 7 Home Premium SP1 64bit
- Intel i5 2410M
- 6GB RAM
- AMD HD 6650M 1GB
For anyone who may come across this, the same thing happened to me just yesterday. I started getting the "Couldn't initialize Direct Draw" on startup after having made a few changes under Preferences -> Display.
I fixed it by going to C:\Users\{user}\AppData\Roaming\Marmalade\ and deleting (or renaming) the preferences.icf file. This isn't removed after an uninstall, so if you find yourself in this situation, this seems to be the only way to reset everything.
Good luck!
A couple of things to try.
First, try running your program from inside Visual C++ by pressing and holding F5. This will cause the simulator to start but won't start executing your program, which might then give you a chance to change the settings in the simulator.
Failing that, if you look in the data directory you should find a file called development.icf which is the current simulator settings. Try deleting this and running again which will cause the simulator to revert to its default settings.
Related
Last weekend my iMac stopped working (sorry forget the symptom details). I tried Disk Utility but it was unable to fix the issue. After I restarted in recovery mode I was able fix the SSD and HD partitions but ended up with a third item. My fusion drive seemed to be split. I found an Apple Support document: https://support.apple.com/en-us/HT207584 and ran 'diskutil cs create Macintosh\ HD disk0 disk1' from the terminal. This seemed to fix the drive.
I was able restore from Time Machine back-up. Got my old mail from BackBlaze. Seemed OK. However, downloaded files (with Safari) gave an error "File damaged and can't be opened. Drag to Trash". I found a fix for file-by-file repair, i.e. xattr -cr Path-to_file. Seemed to work but tedious and didn't really fix the problem. I thought I might make an Automator Folder action to fix the apparent problem with the extended attributes (addressed by the xattr) command. However, when I dragged an (any?) action into the workflow pane I get an error "The action 'Ask the Finder Items' was not loaded because it was detected as malware.
I'm starting to think there is a global permission flag that needs to be flipped.
Any suggestions ideas. Thanks.
Update of sorts. Other files restored from Time Machine are complaining to be damaged not just new downloads.
As reported elsewhere I replaced the file /var/db/gkopaque.bundle with the same file from my laptop via Airdrop. So far so good. Files can be opened. Automator also seems to be working.
I receive this error whenever I try to preview a freshly created swiftui view.
messageRepliedWithError("Connecting to launched interactive agent 9297", Optional(Error Domain=com.apple.dt.ultraviolet.service Code=17 "connectToPreviewHost: Failed to connect to 9297: Error Domain=com.apple.dt.ProcessAttachUtilities Code=3 "Target process 9297 exited prematurely, likely crashed" UserInfo={NSLocalizedDescription=Target process 9297 exited prematurely, likely crashed}" UserInfo={NSLocalizedDescription=connectToPreviewHost: Failed to connect to 9297: Error Domain=com.apple.dt.ProcessAttachUtilities Code=3 "Target process 9297 exited prematurely, likely crashed" UserInfo={NSLocalizedDescription=Target process 9297 exited prematurely, likely crashed}}))
I have no idea how to fix this so I can see previews again. I am on the latest Catalina 10.15.1
I found the Preview Canvas to be extremely buggy as well. Or maybe swiftUI code has a lot of undesired side effects.
In many occasions I found that Clean Build Folder, then kill Xcode, start Xcode, do a full Build may (sometimes) fix the problems. Until I make a tiny change somewhere... Then the whole circus starst again.
In practice this is very time consuming and basically unworkable. I found it more efficient to not use the preview canvas at all and just run the code. It is quicker, more reliable and in the end saves lots of time and frustration.
At the same time I think it is a bit of a shame on Apple. Most frustrating of all (for me at least) is that documentation is virtually non existing. It is all trial and error. Mostly error.
In short: my experience is that it is better not to use swiftUI Previews for anything beyond the very basic (yet).
I had the same problem with mine, I went through a couple of steps, so I will mention everything I did hopefully it helps someone.
But it's worth mentioning that I think the error was caused by Xcode trying to connect to the preview which failed all the time, because I was using an iPhone 8 preview.
Also I was able to use iPhone 8 preview after a while again. This looks like a buggy Xcode.
Steps.
1. Clean build folder and your derived data.
2. Close XCode Completely.
**Key Step. Open Xcode again and change your preview to iPhone XS or iPhone 11.
See the image below.
I had same issue. It was very confusing. I am using FirebaseFirestore pod in my podfile and when I remove FirebaseApp.configure() from AppDelegate didFinishLaunchingWithOptions function preview works.
I have done this 10 times just to make sure that this is an issue, and it was issue for me. So probably any code from Firbase added in that function was problem for me.
So, by checking logs I came across this error:
Crashed Thread: 3 Dispatch queue: com.google.GDTCORFlatFileStorage
Also googling I came across those bugs:
https://github.com/firebase/firebase-ios-sdk/issues/5707
https://github.com/firebase/firebase-ios-sdk/issues/5708
Turning off the thread sanitizer worked for me (I was just playing around with settings against another project that worked), so there's one more thing to try...
This Debugger message pops up randomly while i am attempting to examine a variable while a breakpoint has hit in Visual Studio 2017.
Shortly thereafter, a larger message box appears that shows the following: "Evaluating the function 'System.Reflection.Assembly.LoadForm' timed out."
After enabling option Tools / Options / Debugging / General / Only managed code, the second message box have disappeared. But first message is still showing.
The problem is that first popup window appears for a relatively long time, that makes debugging process very noncomfortable. What else Visual Studio debugger options could I set to disable this popup?
(1)Tools->Options, uncheck the setting Debugging / General / Enable property evaluation and other implicit function call, and enable the Use Managed Compatibility Mode.
(2)Deleted all the .suo/obj/Bin/.user files in your project, and then re-open your project, clean and build your solution, debug it again.
This solution works fine for me:
Uncheck the new langage JavasScript Language Service in Options -> Editor -> JavaScript -> Language Service.
Option capture
I'm having this same issue and there doesn't appear to be a solution. It's extremely frustrating because when the "Getting DataTip text..." does popup and eventually goes away, my breakpoints no longer work.
The solutions listed here have not solved the problem, I've tried them ALL ... even a wipe and re-install of OS and VS 2015.
Debugging without ability to do property evaluation and other implicit function calls is basically NOT debugging and defeats the purpose.
Microsoft seem to be aware of the problem but keep closing the tickets as "unable to replicate" ... yet, a simple Google Search will show many many thousands of hits of developers running into this problem. I keep opening tickets with Microsoft, but they just keep getting closed or merged with no solution.
Cheers, Rob.
The ONLY solution that worked for me:
CMD window (Run As Admin)
type SFC /SCANNOW and wait for it to complete and hopefully fix any errors
Reboot
Bring up VS 2015 or 2017 without loading any project
In VS select Tools | Import and Export Settings | Reset all Setting ... now pick the template you use (i.e. VB, C, Web)
Exit VS
Load VS project and debug
Cheers, Rob.
Old post, but maybe it will help someone anyway ;)
In my case I got this every time I examined the first variable while debugging.
Annoying as hell as I due to the nature of the work restart the debugger often.
This was cause by that the location where my Visual Studio 2017 files were saved, was a cloud drive and it actually had to sync the files before showing the data.
The solution was to mark that whole folder "Always keep on this device".
Cheers,
​Here is one possible solution:
I had this error never seen - then my graphics card (Nvidia) was gone and I removed the graphics card and worked with the integrated Intel. Then I got this error in after 3-4 steps. I installed a Nvidia again and now the "getting data" text message was never shown again.
Btw: this was the fix for the error
"64 bit debugging operation is taking longer than expected"
I had the same issue when I wanted to evaluate variables while debugging in my Unit tests and couldn't find any solution.
This is the solution that helped me: Tools -> Options / Debugging / General. Uncheck "Call string-conversion function on objects in variables windows".
This might only work for some people.
I've experienced this with every version of Visual Studio starting from 2012 (2012, 2013, 2015 Preview), on multiple computers and multiple projects, but I haven't figured out how to fix it:
Whenever I'm debugging a 64-bit(?) C++ console program, after a few minutes and seemingly completely randomly (when I'm not clicking or typing anything), the console window for the program spontaneously closes and I can no longer debug or step through the program with Visual Studio. When I press Stop and attempt to restart debugging, I usually get ERROR_NETWORK_UNREACHABLE:
// MessageId: ERROR_NETWORK_UNREACHABLE
// MessageText:
// The network location cannot be reached. For information about network troubleshooting, see Windows Help.
#define ERROR_NETWORK_UNREACHABLE 1231L
If I try to attach to the process manually I get the error:
Unable to attach to the process.
The only fix I've found for this is to restart Visual Studio. I can't find any other way to fix it, and I've tried running Process Monitor but haven't found anything.
What causes this problem and how can I fix it?
(?) Upon further checking it seems that this only happens in 64-bit mode, but I'm not 100% sure.
Ok, this is just so wrong
I also have issues with this bug, and in my case it occurred every other debug session. Which meant debug -> stop -> debug -> bug -> restart visual studio -> go to start (repeat every minute during the whole day).
Needless to say I was driven to find a solution. So yesterday I tried procmon, spend hours looking at API monitor differences, looked at plugins, netstat, etc, etc, etc. And found nothing. I gave up.
Today
Until today.
To track down a stupid bug in my program today, I launched appverifier. For my application, I ran the 'basics' tests and clicked save. After a few hours this led me to the bug in my program, which was something like this (extremely simplified version):
void* dst = _aligned_malloc(4096, 32);
memcpy(dst, src, 8192);
Obviously this is a bug and obviously it needed fixing. I noticed the error after putting a breakpoint on the memcpy line, which was not executed.
After a stop and 'debug' again I was surprised to find that I could actually debug the program for the second time. And now, several hours later, this annoying bug here hasn't re-emerged.
So what appears to be going on
So... apparently data from my program is bleeding through into the data or execution space of the debugger, which in turn appears to generate the bug.
I see you thinking: No, this shouldn't happen... you're right; but apparently it does.
So how to fix it? Basically fixing your program (more particular: heap corruption issues) seems to make the VS debugger bug go away. Using appverifier.exe (It's in Debugging tools for Windows) will give you a head start.
Why this works
Since VS2012, VC++ uses a different way to manage the heap. Hans Passant explains it here: Does msvcrt uses a different heap for allocations since (vs2012/2010/2013) .
What basically happens is that heap corruption will break your debugger. The AppVerifier basic settings will ensure that a breakpoint is triggered just before the application does something to corrupt the heap.
So, what happens now is that before the process will break the heap, a breakpoint will trigger instead, which usually means you will terminate the process. The net effect is that the heap will still be in-tact before you terminate your program, which means that your debugger will still function.
"Test"
Before using appverifier -- bug triggered every 2 minutes
While using appverifier -- VS debugger has been stable for 5 days (and counting)
This is an environmental problem of course. Always hard to troubleshoot, SysInternals' utilities like Process Monitor and Process Explorer are your primary weapons of choice. Some non-intuitive ways that a network error can be generated while debugging:
Starting with VS2012, the C runtime library had a pretty drastic modification that can cause very hard to diagnose mis-behavior if your program corrupts the heap. Much like #atlaste describes. Since time memorial, the CRT always created its own heap, underlying call was HeapCreate(). No more, it now uses GetProcessHeap(). This is very convenient, much easier now to deal with DLLs that were built with /MT. But with a pretty sharp edge, you can now easily corrupt the memory owned by Microsoft code. Not strongly indicated if you can't reattach a 64-bit program, you'd have to kill msvsmon.exe to clear up the corruption.
The Microsoft Symbol Server supplies PDBs for Microsoft executables. They normally have their source+line-number info stripped, but not all of them. Notably not for the CRT for example. Those PDBs were built on a build server owned by DevDiv in Redmond that had the source code on the F: drive. A few around that were built from the E: drive, Patterns+Practices uses that (unlikely in a C++ program). Your debugger will go look there to try to find source code. That usually ends well, it gives up quickly, but not if your machine uses those drive letters as well. Diagnose by clearing the symbol cache and disabling the symbol server with Tools + Options, Debugging, Symbols.
The winapi suffers from two nasty viral infections it inherited from another OS that add global state to any process. The PATH environmental variable and the default working directory. Use Control Panel + System + Advanced + Environment to have a look at PATH, copy/paste the content of the intentionally small textboxes into a text editor. Make sure it is squeaky clean, some paralysis at the usual mess is normal btw. Take no prisoners. Having trouble with the default directory is much harder to troubleshoot. Both should pop out when you use Process Monitor.
No slamdunk explanations, it is a tough problem, but dark corners you can look in.
I have the same problem. Thought it was related to 64 bit console apps, where it is very easily triggered with almost any debug session. But, it also happens on 64 bit windows apps too. Now I am seeing it on 32 bit windows apps. I am running Windows 8.1 pro on a single desktop with the latest version of vs 2013 and no remote debugging. My (added) extensions are Visual Assist, Advanced Installer, ClangFormat, Code Alignment, Code Compare, Duplicate Selection, Productivity Power Tools 2013, and Visual SVN.
I discovered that the "Visual Studio 2013\Settings\CurrentSettings.vssettings" file gets corrupted. You can delete this file and recreate it by restarting VS or you can try to edit the XML. I then keep a copy of a good settings file that I use to replace when it gets corrupted again.
In my case, the corrupted line begins with
</ToolsOptionsSubCategory><ToolsOptionsSubCategory name="XAML" RegisteredName="XAML"
... and it is extremely long (I think this is why it is prone to corruption).
I just disabled in the Menu
Tools > Options
Debugging > Edit and Continue
Native-only options > Enable native Edit and Continue
and now it does not give the that stupid error which was preventing the starting of the debuggee application.
I also had the same problem with VS2015. It was so frustrating that a simple Hello World program gave this error when I ran debugger for the second time. Tried uninstall and reinstall and didn't work.
Finally, the solution mentioned in https://social.msdn.microsoft.com/Forums/vstudio/en-US/8dce0952-234f-4c18-a71a-1d614b44f256/visual-studios-2012-cannot-findlaunch-project-exe?forum=vsdebug
worked. Reset all visual studio settings using Tools->Import and Export settings. Now the issue is not occurring.
I have an application that is built against OpenSceneGraph (2.6.1) and therefore indirectly OpenGL. The application initializes and begins to run, but then I get the following exception "attempt was made to execute an invalid lock sequence" in OpenGL32.dll. When I re-run it, I sometimes get this exception, and sometimes an exception about a "privileged instruction". The call stack looks like it is corrupted, so I can't really tell exactly where the exception is being thrown from. I ran the app quite a bit a couple of days ago and never saw this behavior. Since then I have added an else clause to a couple of ifs, and that is all. My app is a console application, is built with Visual Studio 2008, and it sets OpenScenGraph to SingleThreaded mode. Anybody seen this before? Any debugging tips?
Can you reproduce it with one of the standard examples?
Can you create a minimal app that causes this?
Do you have a machine with a different brand video card you can test it on (eg Nvidia vs. ATI) there are some issues with openscenegraph and bad OpenGL drivers.
Have you tried posting to osg-users#lists.openscenegraph.org
The problem turned out to be our app was picking up an incorrect version of the OpenGL DLL , instead of the one installed in System32.