I upgraded from 10.3 (Rio) to 10.4 (Sydney) (with side-by-side installs), now having IDE docking exception, e.g.
Loading the desktop from "C:\Users\gary.walker\AppData\Roaming\Embarcadero\BDS\21.0\Default Layout.dst" for doc host windows "DockSite3" failed with message:
"EAccessViolation: Access violation at address 50165CBF in module 'rtl270.bpl'. Read of address 33DEEBFF"
Deleting all .dst files has resolved the issue in at least one case (a coworker).
Also, when attempting to debug a program, I was having a hard failure during debug startup that prevented debugger use, before application began execution. I resolved this problem by copying my Default desktop to my debug desktop.
Another friend had pretty much the same issue and was able to fix it, unfortunately he does not know how he fixed it.
Question is does anyone know how to fix this?
I am still waiting for an answer from Embarcadero and this is causing us real problems at the moment.
I received an answer from Embarcadero support.
It fixed the problem for me until I adjusted my desktops to the way I wanted them and them - still better than nothing. I suspect there is no solid work-around at this point in time. But, this may work well as long as you are not frequently changing your desktop layouts.
There were display layout changes introduced in 10.4.1 that cause the errors that you are seeing.
Shut the IDE down
In Windows Explorer navigate to: %AppData%\Embarcadero\BDS\21.0
Delete the *.dst files at that location (you can back them up first if desired)
In Windows Explorer navigate to the product's \bin directory. The default location is: 4. C:\Program Files (x86)\Embarcadero\Studio\21.0\bin
Copy the three default *.dst files from this location to the location in step 2
Start the IDE as normal
Related
I have the following very weird situation:
Access 2003 MDB application together with a SQL server backend
Application runs from local hard drive using Access Runtime viewer 2010 OR Access 2010
Windows 7 PC
On some PC's users get the infamous unrecognized database format message. It happens at some point while using the application, never at startup. After that the only solution is to stop and restart the application. Same effect, it works for a while and then fails.
Running exact the same version from a network drive does not give any issues. Replacing the Runtime Viewer with a full blown Access did not make any difference. On Windows XP we never had this problem.
Any ideas?
I'm assuming you've tried the usual Repair/Compact by now? Any strange outlier behavior like you're describing usually indicates some form of corruption. At times, corruption goes deep and leaves behind artifacts that can never get resolved. You may want to create a fresh, new DB and import all of the forms/reports/queries/etc... into the fresh DB. This has fixed many issues similar to yours that I've encountered over the years.
Using Visual Studio 2003 Professional under Windows 7 SP1 (64 bit), compiling from the command line, I get a fatal error C1074: IDB is illegal extension for PDB file. The documentation on this error is sparse to put it lightly. The incredibly odd thing about this is that, utilizing the same build script on the same computer but under a different account does not generate this error.
My first guess was that something in the environment variables is causing this conflict, but doing a diff between them for the two accounts, and modifying PATH and INCLUDE to be the same does not fix the error.
Does anyone have a fix for this error, or any idea what actually triggers it? None of the files are being compiled with a /Z switch of any kind, so as far as I can tell, no PDB files should ever actually be generated (and on a successful build, no IDB OR PDB files are generated that I can see).
I was experiencing the same problem with solutions on Windows 7 x64 and Visual Studio 2005 Pro (SP1).
Symptoms
I am using Visual Assist X (currently build 2007). So in my case all I needed to do was to disable IntelliSense by renaming feacp.dl inside C:\Program Files (x86)\Microsoft Visual Studio 8\VC\vcpackages to something else. That fixed the crash at startup (probably unrelated to the issue the OP encountered).
After that the Debug configuration gave me loads of
fatal error C1033: cannot open program database ''
errors, one per file compiled by cl.exe.
With the Release configuration I got
fatal error C1074: 'IDB' is illegal extension for PDB file: <filename>
i.e. the one about which the OP was asking.
Solution
I found the solution more or less by accident elsewhere, reported for VS 2003. In a sense it's the opposite of Luke's answer.
Fatal Error C1074
This error has been reported to occur if the Windows 7 machines have
Windows XP compatibility mode turned on. To resolve the error, turn
off the Windows XP compatibility mode and recompile the solution.
Should you have other issues check the MSDN forums for more help. Its
not the source it sounds more like your settings with VS. I've never
run across this problem before so I'm little help.
That prompted me to check out the settings for devenv.exe (in my case under C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\IDE). It looks like this:
In my case it was set to be compatible with Windows 2003 Server as depicted in the above screenshot. However, the compatibility must be turned off! (checkbox unchecked)
Also make sure to check out and correct the settings for all users by clicking the second highlighted button (UAC prompt will show up if you aren't already running privileged).
This solved the problem for me and I can avoid running VS 2005 Pro elevated all the time.
From information I've gathered on MSDN about issues similar, but not exactly the same:
Since it compiles with no other change than the user account, I believe there's a chance that it could have something to do with the user accounts permissions. Check and see the differences between the users permissions in VS's settings, and in Windows User Settings. The first thing I would try though is to close VS, reopen with Run As Administrator using the account that WON'T compile and see what happens.
In the attempt of sharing the solutions of some of my troubles, and in the hope of sparing them to others, I had the same issue trying to compile a legacy solution in VS2005/SP1 inside a Win8-x64 machine.
No matter what I tried to do, it always stopped there complaining about the illegal IDB extension...
On the other side, the very same solution compiled flawlessly in my previous Win7-x64 box, when run "elevated".
After much struggling I found that I had to use Win8 "Program Compatibility Assistant" (or whatever is named in the english version - my OS is using a different language) and tell it to run VS2005 in a Win7 elevated environment. After that, the obscure "IDB is illegal" error disappeared at once!
Hope this will help someone =)
I am just learning Blend/Silverlight/VS2010/.net/etc. I have a simple project that resides on a network drive. When I tell VS2010 to rebuild the project, I get the following error message:
------ Rebuild All started: Project: MySilverlightApplication, Configuration: Debug Any CPU ------
MySilverlightApplication -> H:\PRJ\VisualStudio\ExpressionBlend\Unleashed\MySilverLightApplication\MySilverlightApplication\Bin\Debug\MySilverlightApplication.dll
C:\Program Files\MSBuild\Microsoft\Silverlight\v4.0\Microsoft.Silverlight.Common.targets(214,9):
error : Could not load the assembly
file:///H:\PRJ\VisualStudio\ExpressionBlend\Unleashed\MySilverLightApplication\MySilverlightApplication\obj\Debug\MySilverlightApplication.dll.
This assembly may have been downloaded from the Web. If an assembly has been downloaded from the Web,
it is flagged by Windows as being a Web file, even if it resides on the local computer.
This may prevent it from being used in your project. You can change this designation by changing the file properties.
Only unblock assemblies that you trust. See http://go.microsoft.com/fwlink/?LinkId=179545 for more information.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
The project was not downloaded from the Web (I created it using Blend.) After doing some searching, I guessed the problem may be due to .net security settings. I issued the following command:
C:\Program Files\Microsoft Visual Studio 10.0\VC>caspol -m -ag 1.3 -url "file://\\p4dc\h$\*" FullTrust
in the hope that would solve the problem. p4dc is the name of the server machine, h$ is the administrative share for the h: drive on the server which in turn is mapped to the drive letter "H" on the local machine (\\p4dc\h$ is mapped to H in the local machine).
That did not solve the problem. I don't know if my caspol command is correct (I wasn't planning on learning caspol on the fly), it just seemed like a reasonable thing to try. The problem goes away when I make a copy of the entire project on the local C drive but, that "solution" is rather undesirable.
At this point, I don't really know what else to try to solve the problem without moving the project to a local drive.
Any help leading to a solution is much appreciated.
John.
The error message displayed by VS2010 would lead anyone to believe the issue is with trust and security and it is BUT, no amount of allowing full trust on the network drive will solve the problem.
What lead to the solution was first to port the project to VS2008 to find out if it would encounter the same problem. VS2008 was perfectly happy to run the project without complaint.
Then I converted the VS2008 project (which was working) to VS2010. VS2010 refused to build the project but this time the error message was different, referring to "remote assemblies" and to a link on MSDN, which led to the solution.
The real problem is that VS2010 considers an assembly on a network drive a "remote assembly" (the same as if the assembly were being loaded from a web site.) Caspol was not able to solve that problem (it seems it should have but, it may be my fault, I am not well versed in using Caspol).
To end this long story, the link provided in the error message is:
http://msdn.microsoft.com/en-us/library/dd409252(VS.100).aspx
after following the instructions in that link to edit "machine.config", I changed <runtime/> to:
<runtime>
<loadFromRemoteSources enabled="true"/>
</runtime>
the project built successfully and ran without a hitch.
Thank you to Alison and CodeNaked for their efforts to help,
John.
PS: it would have been rather nice if VS2010 had displayed the "better" error message initially. Instead, I had to port the VS2010 non working project to VS2008 where it worked and that one to VS2010 where I got the better error message that led to the solution.
Not sure if this will help but it's worth a shot: How Do I Allow my Visual Studio .NET Projects to Run from a Network Location?
I just discovered this problem today, and I had no idea what caused this problem. My project had been developed for few months.
I have a project(solution), with several projects in there, it works well if I write and debug, by pressing F5.
The problem occur is when I press Ctrl+F5 (to skip debug mode), or run directly from double click the exe, it crashed. The errors dialogs that pop up every times are different, but OutOfMemoryException is the most frequent one.
I had checked to make sure all my projects are .Net 3.5
I put a MessageBox.Show("something") at the beginning of my main project constructor, but it never reach.
I use some registry cleaner to clean/fix my registry, scan for viruses.
I had try to read the meaning of each error and exception, but still no clue why it happen.
These are a series of screenshots if I press Ctrl + F5. (FutureGenerator is some random name I gave to my project.)
Series of screenshot if I run the app from my debug folder, FutureGenerator.exe
I suspect this is caused by framework crashed during Windows Update, but I removed those update that I performed recently, still same. The exe file works on other non development PC, but I don't want to reformat my PC or reinstall my VS, yet, because it's a painful process.
Any idea, anyone?? Million thanks.
You mention v3.5 but the very first screenshot is about v4.
Try repairing your Framework 4 and/or VS2010
I found the problem. It's actually because I added FutureGenerator.exe into Application Verifier by Microsoft. The verifier only support debugging testing.
After I removed FutureGenerator.exe from the Application Verifier, everything's ok.
I'm trying to add a .settings file in a windows form application by adding a (whatever) file in the project and have it named smthng.settings. Right after it is created, it crashes (if I look into the project's directory the file is there, but it's not "in" the project). Am I doing it wrong or could it be that the problem lies elsewhere?
Edit: It seems that it's the settings designer that crashes.
Partially Solved:If I add a (whatever).config file, then rename it to .settings and change it's file type to C/C++ Code (don't ask how I figured this out..) then I can add to it settings, but if I do add something that has any connection to the form then automatically a (whatever).config with thew same name spawns (which is identical to the (whatever).setting even if change one of them) and at the stdafx.cpp a #include '(whatever).h' appears, which is a problem, because there is not such a header. (if I erase it or just create a blank (whatever).h it doesn't work. Apparently I have to somehow connect all the data in the (w/e).settings to (w/e).h as well or maybe something else) Anyone had this problem before? Anyone has any ideas?
If it crashes, then regarding of what else you may be doing wrong, it's a bug - software shouldn't crash on invalid user input. That said, the causes could be anything from bug in VS itself, to bug in some third-party extension you're using, to system problems.
Make sure you have all the latest OS updates and service packs for VS2005. If it still repros then, report it as a bug to Microsoft Connect, and people responsible for this product area will take it from there.