Fixing MSVC Compiler Error C1074: Illegal extension - c

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 =)

Related

EAccessViolation error when loading or switching desktops

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

running Winform Application

detailed message box texti made a winform application on my pc and it runs fine. but when I tried to run it on another PC by copying the exe file and other dll files there , the application failed to run and all of a sudden it shows a dialog box to close the aplication.
please refer to screenshot of error.
enter image description here
Like bassfader said: One possible explanation is that your application is handling files during startup. In that case: integrate more extensive exception handling for those parts. Potentially with logging, to locate the problem
In my experience this however is more often a case of missing some kind of dependency.
Double check .NET runtimes. Lookup the target .net version in Visual Studio and run the installer on the target machine.
Investigate if your app uses any assemblies that are not part of the .NET framework. Sometimes these are not copied to the bin directory if they are in the GAC (ensure the flag "Copy Local" is set to "Always" in Visual Studio)
Ensure you have copied the whole bin folder
Check compiler output to see if you've got Platform mismatches. IIRC this can sometimes work fine on a dev machine but cause problems when Visual Studio is missing or you get to a different OS.

Visual Studio Debugger not breaking when function (in external .net dll) is hit

I followed the steps described here to break when a function defined in an external dll is hit, however its not working for me. Maybe I am missing a setting. How can I get it to work?
Checklist:
- Enable just my code is disabled
- Symbols for external dll (System.Data.Entity.dll) appear to have been loaded (see below)
EDIT: the answer is to compile the code as 32 bit. It worked for me, can't say if it will work for others.
Some notes: There is a useful tool to know about. Its called srctool.exe. It comes with Debugging Tools for Windows and got installed under c:\Program Files\Debugging Tools for Windows (x64)\srcsrv on my machine. You can run it on a pdb file and it will tell you whether file has been source indexed or not. If the pdb file is source-indexed, then there is a link embedded in the pdb file which points to a location from where the source code can be fetched. E.g., I see this output from srctool.exe:
[f:\dd\ndp\fx\src\DataEntity\System\Data\Objects\DataClasses\RelatedEnd.cs] trg: http://referencesource.microsoft.com/source/NET/4.5/net//ndp/fx/src/DataEntity/System/Data/Objects/DataClasses/RelatedEnd.cs/550320/RelatedEnd.cs
What if pdb file is not source indexed? Does it mean VS will not be able to show you the source, step-in etc.? I think so, though I am not an expert. I found this link to be semi-useful.
Anyway, coming back, for me, fetching code from the embedded link in pdb file meant running this command (VS will give you a popup where it will ask you to run the command; if it fails you won't know; only way to know if it succeeded is to run it yourself from a console) which gave an error.
tf.exe view /version:550320 /noprompt “$/[omitted]/[file].cs” /server:http://[omitted] /console > [file.cs]
To get around this limitation, I manually downloaded .net framework source code from http://referencesource.microsoft.com/netframework.aspx. There was a problem here also: the file gets downloaded as .aspx which doesn't do anything. Turns out you have to rename to .msi. Then run the executable. See this link: http://social.msdn.microsoft.com/Forums/en-US/refsourceserver/thread/f17c11c1-72f6-4529-bafe-5a1d79b72bd7
I just can't believe how many issues I ran into.

Silverlight project build fails in VS2010 when project is on a mapped network drive

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?

VS 2010 loading slow - Xap packaging failed. Exception of type 'System.OutOfMemoryException' was thrown

I'm having an issue with VS 2010. It's running very slow and also crashes occasionally when compiling and packaging a xap file with the following error:
Xap packaging failed. Exception of type 'System.OutOfMemoryException' was thrown.
In the local Windows 7 temp directory \Users\usernamexxxx\AppData\Local\Temp
there are thousands of files, so I removed them and now VS is much faster.
Is anyone else having similar issues?
Yes, I have simmilar issue. when I clear My Temp Memory It works fine but after some time Temp directory is also showing some file.
and again the message comes "Out of Memory Exception".
It is an issue in Code. Your code is leaking memory. your code is not disposing object properly.
I haven't had that type of error message, but the thing that always seems to slow down VS 2010 for me is the .suo (Solution User Options) file. It basically keeps track of what files you have open, and your break points, but it is an always growing file. When it get's up to 5mb, it can take 20-30 seconds for VS to respond at times when adding a file, or deleting one from the solution.
I got tired very quickly of visual studio's slowness. My solution was to build everything on the command line using msbuild. I created a batch file which calls msbuild with my preferred options.
This option is actually really nice, because if you have a multi-core machine, you can pass the /m flag to msbuild, which will allow the build projects in parallel when possible (Visual Studio currently doesn't offer this functionality, but will in VS2012)
Calling msbuild is easy. For example:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\msbuild.exe MyApplication.sln /m
Then, if I want to debug, I just build first (on the command line), run the app, and attach the visual studio debugger manually.
I'm not familiar with this error in particular, but had an nasty issue back then with OutOfMemoryException during compile time for a big solution (more than 50 projects)
We used to circumvent it by using msbuild directly but debugging was a bit cumbersome
I checked on internet then and tried to extend the virtual memory that devenv.exe was using (by default it's 2GB).
Being on a 64bit Windows 7, the OS was already complying with the fact that an application could use more than 2GB.
Just had to fire up a command prompt and type :
cd\
cd "C:\Program Files (x86)\Microsoft Visual Studio 10.0"
copy Common7\IDE\devenv.exe Common7\IDE\_devenv.exe
VC\bin\editbin.exe /LARGEADDRESSAW Common7\IDE\devenv.exe
After a reboot, the compilation Exception was just a mere dream.
Note : I read afterward that Visual Studio 2010 was supposed to be Large Address Aware out of the box, so it shouldn't have "solved" my issue, but it did for me.

Resources