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.
Related
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).
I have come across this particular problem several times across several versions of the IAR embedded workbench (EW430 5.40.7 [EW 6.0], EW430 5.51.2 [EW 6.4], EW430 6.20.1 [EW 7.0]), but each time only after a long period of having no problems. The problem doesn't seem to have affected the other firmware developers in the office, so no help can be offered there. I'm currently on Windows 10, but the problems first occurred when I was on Windows 8.1 (same PC.)
The problem is that, for no obvious trigger, the IAR ide will start to hang until terminated (or it will just crash on one of the EW versions) on any attempt to change the active build configuration in MSP430 projects using the emulator.
From my testing, it appears to be directly related to something the IDE is doing with the emulator, as when the build configuration is changed, I can see the emulator menu in the menu bar disappear, then the hang happens. Under normal circumstances, the menu will disappear, but then reappear once the other debug configuration is completely loaded.
I have tried the default project "flashing the LED" to see if it was only my project - but if I select the msp430x4xx (C) - Debug, right click it and select "Set as Active" from the context menu, to make this the active project, the IDE also hung. I then reopened the EW IDE, and opened the LED flashing project again. The original 1xx asm project was the active project.
I then changed the settings of the 4xx (C) Debug project (without making it the active project) from the emulator to the simulator, and clicked OK. The program did NOT crash.
I then set the 4xx (C) Debug project as the active project and it did NOT crash. The simulator even runs without problems.
The version of the FET firmware didn't change from when the IDE worked correctly to when it didn't, and the FET is not even used at this point. It can be completely disconnected and the same results will occur.
I have tried the following, without success:
erasing the files in my project folder's settings subfolder
erasing the *.dep files in the project folder.
deleting the IarIdePm.ini file from AppData\Roaming\IAR Embedded Workbench
making sure none of the project files are read-only
reinstalling the program to the same location
removing and reinstalling the program to the same location.
What does solve the problem (until it reoccurs) is to reinstall the program, but to a different directory (for e.g., the default directory will be in program files (x86)\IAR Systems\Embedded Workbench x.x. Installing again into program files (x86)\IAR Systems\EWx (just so it is different) allowed that installation to work, but the old installation continued to fail.
Best advice so far (from our support person) has been to do the above, install to another directory and live with it, as it doesn't happen often.
Since it has happened to me on 3 occasions with 3 different versions of the program, I would like to know how to fix or prevent it! If anyone could offer anything to try (or even better, a straight solution :)) that would be greatly appreciated!
Cheers!
Since newer versions and updates on W10, it seems that old compatibilities are being removed from this OS. I have no direct solution for this problem since Microsoft does not promise support for old software and hardware. Even I tried to find a solution for that problem, and I found on the IAR website a list of IDE's and their compatible versions. (remember, old versions are not compatible)
( https://www.iar.com/knowledge/support/technical-notes/ide/windows-10-and-iar-embedded-workbench/ )
You will need to update your IDE and program version to a newer version if you plan to continue to use this IDE natively on Windows 10 or you may use Virtual machines with an old operational system (like Windows 7) to compile your program on old IDE.
P.S.1 I manually uninstalled KB4592449 recently updated and the program return to work natively. Probably it will continue working until this update (or other similar) being installed again on the computer, but probably there is any vulnerability that the computer will be exposed to, and in this case, I'm paying the price.
P.S.2 KB4580325 promotes the same behavior in IAR 5.11 on windows 10. Both KB's implement securities about the flash player - that I Don't use - then, I can securely uninstall it.
P.S.3 Since I updated my windows up to Windows 10 version 21H1 (compilation 19043.1165) AND I configured Windows defender to not be monitoring IAR IDE (IarIdePM.exe) disabling all protections available, everything works fine. But Remember: my program is original, not cracked or altered by anything, then I am secure to do what I did.
It is a 'natural' that software problem. Not found way of fixing it. The solution temporary is modify manually the file .eww for change of project active. The ultimate solution is to use another development environment.
I'm having problems running the FreePascal IDE (for Win32 for i386) Version 1.0.12 2011/04/23 Compiler Version 2.4.4. It crashes when I want to "Open" and "Save as"
When I select one of those options in the Menu the IDE returns: "Program generated a RTE 215 at address $00696A49" which prompts me to close the IDE, and then shows three addresses in a separate window: $00696A49 and 2 others (random).
If you need to know, I have been loading .pas files from directories other than FP's own, and the IDE used to show "couldn't load file from current directory"-like messages.
I want to know what's generating this problem and if I have to update it.
Thanks in advance.
Despite 2.4.4 being an older release, it shouldn't happen with a win32 release in normal situations (like on harddisk, not network drive, no special permissions in sight).
You could try using a different system and see if it fails there too, or try a newer version.
I started a new application and changed the target framework to v2.0 for Windows XP compatibility but when I run the debugger (with or without code) I get an error saying MSVSMON.exe appears to not be running. I tried restarting the project and even changing the target framework back to v4.5 but I still get the error. How do I fix this?
I know this is quite old, but in case somebody has the same issue I thought I'll answer it. I changed the platform target to 32bit and debugging worked. Setting it to 64 bit or Any CPU caused the error you are describing. Not really the perfect solution but at least I can debug now.
I have recently put together a new development machine and loaded Windows 7 64 bit and VS2010.
I copied over all my projects (VB) from the old machine which was Windows 7 x86 and VS2008.
After following the conversion wizard in VS2010 and installing a third-party component I had forgotten about, my solutions opened and executed fine on the new machine.
Then I tried to work on one of my projects via RDP from a Windows XP machine (something I have done many, many times with the old machine) and the project crashes when run. I get the "no source availiable" tab and an AccessViolationException as soon as the splash screen has loaded. Going back to local operation, the project runs fine.
I've Googled this one to death and I can't find anything that relates to this problem at all. Any sugggestions would be gratefully received.
Thanks.
I do have multiple monitors but have never had a problem before with RDP. Anyways, I found other problems when opening other, older, projects in VS2010 so I uninstalled and reverted to VS2008. All OK now. Thanks for your help.
I was having an issue running Visual Studio 2010 via RDP where the IDE contents except the Solution Explorer wouldn't render. I went to Options->Environment->General->Visual experience and turned off the the "rich client visual experience" options. I suspect turning off "Use hardware graphics acceleration if available" did the trick.
I had also problem with RDP working in "windows 10"
My connection other computers always run successful, but closing after 5-15 second. I very long try fix this error. And I open this exception in VS2015 and read full excaption:
Unhandled exception at 0x00007FFBE35A8283 (ntdll.dll) in mstsc.exe: 0xC0000374: Куча была повреждена (parameters: 0x00007FFBE35FF6B0).
At first I thinked my PC have truble with RAM memory, but I decide change RDP settings and it began work without problem.
I changed the picture quality and uncheck using printer in other window.
My rdp workin very nice now.
I tried many fixes
From the microsoftware, with updates and system files, but nothing helped. I am writing now if someone with the same collision can solve temporarily the problem by lowering the quality of the picture. On a remote computer, it may be very important to simply connect, especially if it is a server.