Why I see ”Embedding manifest…” message in Output window?

Well, time flies fast. It was two month since my last post here. One may ask what I was doing all this time. Answer is simple – working. 🙂 Seriously, VC++ program management team has spent a lot of time in preparing and then running VC++ Tour in Europe. There is long slides deck with information on all features coming in VC++ 2005 and several demos for most frequently asked features. Take a look on official page for this trip for more information http://msdn.microsoft.com/visualc/community/Tour2005/ . Also during our stop in Norway, my laptop was ambushed by Pepsi. It was seriously damaged and for the rest of the trip I was only able to check my emails from internet cafes. However very soon I started to have issues with remote connectivity, and that was the end of e-life for me. Anyway, it is the second week I am back in my office and hopefully I will post more regularly now.


So if you use VS2005 Beta 2 (yes, yes, it is available now, go ahead and download it if you have not done this already), you may have already noticed a message saying “Embedding manifest…” when you are building you project. You may also notice that linking starts second time sometimes after this message. You may ask yourself, what is going on and why we link twice. Actually 2nd link starts only if incremental linking or edit-and-continue is enabled. By default Visual Studio tryes embedding manifest for each project, unless users explicitly changes Manifest Tool -> Input and Output -> Embed Manifest property in Project Properties dialog. If the user selects to not embed manifest, manifest is generated as an external file and saved in the same directory where the final binary is. If the user chooses to embed the manifest, IDE embeds final manifests using the following process:

1. After the user code is compiled to object files, the linker collects dependent assembly information and while linking the final binary it generates an intermediate manifest that is used later to generate the final manifest.

2. After the intermediate manifest and linking are finished, the manifest tool will be executed to merge a final manifest.

3. If neither incremental linking nor edit-and-continue are enabled, mt.exe embeds the final manifest into the binary. If incremental linking or edit-and-continue is enabled, mt.exe save it as an external file. And project system is going to start second incremental linking to embed this external file.

4. Project build system then detects whether the manifest generated by the manifest tool contains different information then the manifest already embedded in the binary.

5. If the manifest embedded in the binary is different from the manifest generated by the manifest tool or binary does not contain an embedded manifest, IDE will invoke the linker one more time to embed the external manifest file inside the binary as a resource.

6. If the manifest embedded in the binary is the same as the manifest generated by the manifest tool, the build will continue to the next build steps.

So why does IDE need steps 4-6? The issue here is that in order for incremental linking to work, no changes should be made to the binary after it was linked by the linker. If mt.exe embeds manifest after the linker, the on the next incremental link, the linker detects the change and spins the full build. But if IDE creates a resource file with the final manifest and ask the linker to link this resource with the already built binary, for the linker this is a simple and very quick job to do. Moreover after resource is embedded, the binary is still correctly formed for the next incremental link. Nice trick by IDE, isn’t it?


Manifest is embedded inside the final binary as a text resource and it can be viewed by opening the final binary as a file in Visual Studio. Just open this binary in IDE and you see binary resource. Export it and you can now view it with any text editor. Actually this is the first step when I need to debug why this binary does not load.


So the fair question is what someone does to existing makefiles? Well, I have posted a sample where I have shown how to change a makefiles used to build both EXE and DLL. You may find it here How to embed manifest inside C/C++ program using makefiles.


Questions? Please feel free to post any comments below, I will try replying asap.

Comments (9)

  1. With VC 2005 the native libraries such as the CRT, MFC, and ATL can now be installed as Side by Side…

  2. jorn says:

    Is there any way one can disable the use of side-by-side (and activation contexts) for the new C++/MFC binaries?

    I have an application written with VS2003 and it works fine when activated/deativated through COM inplace COM interfaces. But now the app has been recompiled with VS2005 and I get the STATUS_SXS_EARLY_DEACTIVATION exception when it is UIDeactivated.

    Any suggestions?

  3. Nikola Dudar says:

    No, with VS2005 we are not supporting building applications without manifest. As for the error, please make sure manifest are correct and list correct dependencies. If these are DLLs, then manifest should be embedded with ID=2. Check out troubleshooting page on MSDN, http://msdn2.microsoft.com/en-us/library/ms235342.aspx. You may also check with community on forums, http://forums.microsoft.com/msdn/ShowForum.aspx?ForumID=29



  4. jorn says:

    Hi Nikola

    Alle manifests and dependencies are correct. Do you have any good pointers of how to debug/troubleshoot problems like this? Is it possible to somehow see/follow the stack of activation contexts being pushed and popped?



  5. Nikola Dudar says:


    There is troubleshooting section of the docs with list of things to check, http://msdn2.microsoft.com/en-us/library/ms235342.aspx. There is also many experienced devs on forums that can help you with troubleshooting the problem, http://forums.microsoft.com/msdn/ShowForum.aspx?ForumID=29.



  6. paul metieh says:

    How do u link a .res file created by the rc.exe compiler in visual C++ 2005 express edition?

  7. ppetree says:

    This whole manifest concept is FUBAR.

    I have a simple service that right now consists of two threads, the main thread that essentially does nothing more than a WFSO and a child thread that does IO on a named pipe.  There is no dynamically allocated data, no application supplied dlls.  Nothing outside of the normal base calls in a win32 service.

    After every ConnectNamedPipe, read, write, DisconnectNamedPipe() in the child thread I get an exception in the main thread with an error that says:

    The activation context being deactivated is not active for the current thread of execution.  No where can I find out how to debug this or how to fix it!  This same simple service runs just fine on win2000!

    How do we resolve this?


  8. csb says:

    Hmm… I’m running into the same error: "The activation context being deactivated is not active for the current thread of execution." when my MMC snapin extension is being loaded.  It works fine when compiled in VS7.1, but now I get this error when compiled with VS8.  It happens in mmc.exe soon after my dll is loaded, but there is no useful context or any clue to me what could be causing this.  Learning about all the hacks involved with the activation context and manifests in VS8 isn’t how I wanted to spend my day…

  9. Eric says:

    I didn’t understand a word you said. Can you explain this stuff in terms that a newbie programmer can understand?