News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

LNK4209: Debugging information corrupt

Started by Leaeaxedx, November 16, 2017, 11:22:25 PM

Previous topic - Next topic

Leaeaxedx

Visual studio 2017 changed the obj's debug info format. So the linker gives me "Warning LNK4209: debugging information corrupt,...." on every obj created by HJWASm/UASM.

Any chance the Uasm will support the new debug format in a near future?

VS 2017 Preview 3 suppose to solve this, but I can not confirm it. Still it would be nice to support the new format.

Regards,

Leaeaxedx

BTW: Great work with Uasm, hope you will keep its support for many years.  :t

LiaoMi

Hi,

most likely the reason is in other parameters. Give an example of your project that causes this error. I could not find any information about updating  :icon_confused:

Information from Microsoft about the PDB format https://github.com/Microsoft/microsoft-pdb

Linker Tools Warning LNK4209
debugging information corrupt; recompile module; linking object as if no debug info
The file contains bad CV information; recompile the module and relink.

johnsa

Hi,

Apparently the latest update of 2017 was supposed to solve this but it didn't work for me.

What i did find however is the solution depends on which version of link you try and use, for me the logical one wasn't right, (I had assumed HostX64) and instead I need to use this link version:

"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.10.25017\bin\HostX86\x64\link.exe"

This version doesn't produce the PDB error.

Leaeaxedx

Thanks for your replies.

On Microsoft Visual studio Developer Community site this I got as the reply on the same issue:

-------------------------------------------
Solution by Lars Wood29. 9. 2017 01:42:00
The reason this happens is that Microsoft changed the format of the debug information created when building a .obj file in this release and so if you have .asm files, for example, that were built with an old version of masm, for example, or if these object files or likewise were built with the old format using some other tool presumably and in any event are part of a library then the linker generates this error. so for example if this file, in the example below, is built with an older masm and the object file then becomes part of a library, when the library is linked into an .exe or .dll file you get the link error (but not before you link into a .dll or .exe).

..\masm611\bin\ml /Zi /Zf /Zd /coff /c /Fo "%(Filename)"_dbg_info.obj "%(FullPath)"

by removing switches that create .obj debug info the problem goes away. Reassemble, rebuild the library and re-link application.

..\masm611\bin\ml /coff /c /Fo "%(Filename)"_no_dbg_info.obj "%(FullPath)"

In summary, the problem is the old debug info format that goes into a .obj file is not compatible with the new .obj debug info format. The .obj files with the incompatible debug format lurk inside library files. The problem only presents itself when the library file is linked into an application. The solution is to rebuild the .obj file and then relink the library and then link the application into a .exe or .dll etc. If you are linking against an old library file an incompatible .obj may be lurking within it. Either update to the most resent library files or if the library files are your own rebuild with up to date compiler or assembler generating the new .obj debug info format. If you are using an old assembler simply turning off the switches that build the .obj with the incompatible debug information will fix the problem. No error or warning is given until you link the library containing the incompatible .obj debug into a .dll or .exe file. The problem is in the .obj files with bad debug info, disabling debug info generation when building the .obj with the older compiler or assembler also solves the problem. I doubt that Microsoft will change or fix this (the complexity required is not worth it) since it would mean they would need to support two .obj debug info formats, i.e. the old format and the new format. Note the linker when generating the error at .dll or .exe link time tells the name of the offending .obj file lurking within a problem library.

------------------------------------------------------------------------------------

The VS 2017 Preview suppose to solve this, but still It looks like a new debug format is in use since VS 2017.3 I guess.

Regards

fearless

Here is the link to the issue posted on the dev community thing: https://developercommunity.visualstudio.com/content/problem/95867/fatal-error-lnk1103-debugging-information-corrupt.html

Leaeaxedx

Quote from: fearless on November 28, 2017, 02:29:48 AM
Here is the link to the issue posted on the dev community thing: https://developercommunity.visualstudio.com/content/problem/95867/fatal-error-lnk1103-debugging-information-corrupt.html

The solution I have posted is from the same page...lol.

johnsa

I'm not sure I buy there answer.. apparently 15.5 pre-release is working..?

IF they did change the debug info format in obj files, they be duty bound to support both old and new formats alike, a) this wouldn't have been more work as the existing format logic would already be present and b) how could they possibly justify changing a mandatory and essential part of the entire build process without warning possibly breaking millions of sources, tools and libs that simply cannot be re-compiled against this latest version... also why would it work with 15.2 and 15.5 (but not 15.3) a minor version increment like that shouldn't be introducing features like a completely new format for debug information, also given that MS rely mainly on their PDB file format for more complex/extensive debugging data support for .net etc...

Leaeaxedx

Quote from: johnsa on November 28, 2017, 05:45:05 AM
I'm not sure I buy there answer.. apparently 15.5 pre-release is working..?

IF they did change the debug info format in obj files, they be duty bound to support both old and new formats alike, a) this wouldn't have been more work as the existing format logic would already be present and b) how could they possibly justify changing a mandatory and essential part of the entire build process without warning possibly breaking millions of sources, tools and libs that simply cannot be re-compiled against this latest version... also why would it work with 15.2 and 15.5 (but not 15.3) a minor version increment like that shouldn't be introducing features like a completely new format for debug information, also given that MS rely mainly on their PDB file format for more complex/extensive debugging data support for .net etc...

I couldn't agree more!

Today 15.4.5 update is out so I'll upgrade the VS later this day and come back with more info.

johnsa

Ok, well I updated to 14.4.5.. I still don't ever get :

Linker Tools Warning LNK4209
debugging information corrupt; recompile module; linking object as if no debug info
The file contains bad CV information; recompile the module and relink.

But I do still get exactly the same issue as before which is :

fatal error LNK1318: Unexpected PDB error; OK (0) ''

This later issue for some reason doesn't occur when I use the version of link i mentioned before from the x86 host folder instead of x64.

Let me know how you get on with the first issue, if perhaps deleting all the intermediate files helps (ilk, pdb etc). Or possibly terminating the symbol services I've seen mentioned in some posts.

johnsa

Ok, after updating I now get :


fatal error LNK1318: Unexpected PDB error; OK (0) ''
when trying to use HostX64 version

AND

Linker Tools Warning LNK4209
debugging information corrupt; recompile module; linking object as if no debug info
The file contains bad CV information; recompile the module and relink.
when trying to use HostX86 version

... WTF ...

johnsa

Apparently the fix is ONLY in VS 2 017 15.5, which is still only in pre-release and has been for months.. they're now on 5 which I'm busy downloading:

https://www.visualstudio.com/en-us/news/releasenotes/vs2017-preview-relnotes

I will let you know if this helps.

johnsa

I can confirm pre-release of 15.5 fixes

Linker Tools Warning LNK4209
debugging information corrupt; recompile module; linking object as if no debug info
The file contains bad CV information; recompile the module and relink.

This is using the link found in the HostX86 folder.

The link in HostX64 however still produces this error:
fatal error LNK1318: Unexpected PDB error; OK (0) ''

Leaeaxedx

Quote from: johnsa on December 02, 2017, 03:39:17 AM
I can confirm pre-release of 15.5 fixes

Linker Tools Warning LNK4209
debugging information corrupt; recompile module; linking object as if no debug info
The file contains bad CV information; recompile the module and relink.

This is using the link found in the HostX86 folder.

The link in HostX64 however still produces this error:
fatal error LNK1318: Unexpected PDB error; OK (0) ''

Thanks, johnsa.

I'm not sure using a linker from previous VS versions is a good idea. Pdb error must be generated by debugger because the format generated by "an old linker" is not the correct one.

Looks like 15.5.xx Preview resolve this issue, but for now the VS Preview gets installed side-by-side, which I don't like it at all. I'll wait for the release version (= update of the current version 15.4.xx). I agree it's taking quite a lot of time since the issue was reported for the first time.

Thanks for all you effort.

Regards,

Igor

johnsa

I'm tempted to report the other PDB error to MS as well, as clearly these are new issues that didn't exist before, they've cocked something up in Link.. and it's only been since the middle of the year.. Not that I think they'll take much notice.. :)

Leaeaxedx

VS 2017 15.5 is now available as regular update (not as as side-by-side Preview instance).

I have just updated VS 15.4 to 15.5.

There is no linker error any more, so this update solved the pdb format issue.

Works like a charm.

:t