none
_except_handler4_common

    Question

  • Hello all, I am having this problem with deploying applications onto Windows XP. I have visual studio installed on my vista machine and it is obviously looking for the newer lib calls which don't exist.

     

    I tried using

    #pragma comment(lib, "C:\\Program Files\\Microsoft Visual Studio 8\\VC\\lib\\msvcrt.lib")

    #pragma comment(linker, "/NODEFAULTLIB:C:\\path\\msvcrt.lib")

     

    fatal error LNK1276: invalid directive 'Files\Microsoft' found; does not start with '/'

     

    I heard there was an update which I believe I have installed which does not fix my issue but if anyone has the link to this, I would be glad to have a look.

    Friday, August 24, 2007 12:52 PM

Answers

  • This is due to the spaces in the path e.g. Program Files , Microsoft Visual Studio 8 etc.

    Why do you need to specify the path  ? Isn't  #pragma comment(lib ,  "msvcrt.lib") sufficient?  $(VCInstallDir)lib in the IDE VC++ directories setting means the same thing as C:\\Program Files\\Microsoft Visual Studio 8\\VC\\lib

    Saturday, August 25, 2007 1:00 AM
  • It's because the version of msvcrt.dll is different.  Please see this discussion

    http://www.thescripts.com/forum/thread611031.html

    Saturday, August 25, 2007 9:53 AM

All replies

  • This is due to the spaces in the path e.g. Program Files , Microsoft Visual Studio 8 etc.

    Why do you need to specify the path  ? Isn't  #pragma comment(lib ,  "msvcrt.lib") sufficient?  $(VCInstallDir)lib in the IDE VC++ directories setting means the same thing as C:\\Program Files\\Microsoft Visual Studio 8\\VC\\lib

    Saturday, August 25, 2007 1:00 AM
  •  

    I get the _except_handler4_common in msvcrt.dll is missing on XP computers, so I thought that VS2005 might be pulling the wrong library file to link with. Though this may not be true, what other fixes can I try?
    Saturday, August 25, 2007 8:02 AM
  • It's because the version of msvcrt.dll is different.  Please see this discussion

    http://www.thescripts.com/forum/thread611031.html

    Saturday, August 25, 2007 9:53 AM
  • The solutions in that thread do not work for me.

    Sunday, September 02, 2007 9:07 AM
  • There are actually two things mixed up here: the import library (actually there's some static code in there, too) and the actual DLLs.

     

    In VC8 there is a msvcrt.lib which should result in a dependency on msvcr80.dll _not_ msvcrt.dll. Is this the case for you (Depends.exe will tell you, for instance)? If so, you have the wrong msvcrt.lib. In fact, user (non-OS) components are not supposed to link to msvcrt.dll (that's the DLL and _not_ the import library here! - msvcrt.dll is a OS-specific implementation of the CRT).

     

    The /VERBOSE:LIB linker switch should tell you which msvcrt.lib is selected.

     

    Also, there's no need to explicitly specify the dependency on msvcrt.lib. The compiler emits that automatically with /MD (unless /Zl is also specified).

     

    -hg

     

    Sunday, September 02, 2007 3:50 PM
  •  

    Okay, I found my problem was because I was including the Vista winsock32.dll (Due to msvcrt.dll being reference, Thanks Dependacy Walker) within my deployment, I removed that from the folder containing my program which enables my code to run. I now have another problem and unsure why it will not run further due to an interesting error.

     

    "Error creating login window: -2147023728" (Note: This is my internal error message box)

     

    Code Snippet

    const char g_szClassName[] = "TheMUDClient";

    int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd) {

    InitCommonControls();

    WNDCLASSEX wc;

    MSG Msg;

    wc.cbSize = sizeof(WNDCLASSEX);

    wc.style = 0;

    wc.lpfnWndProc = WndProc;

    wc.cbClsExtra = 0;

    wc.cbWndExtra = 0;

    wc.hInstance = hInstance;

    wc.hIcon = LoadIcon(NULL, IDI_APPLICATION);

    wc.hCursor = LoadCursor(NULL, IDC_ARROW);

    wc.hbrBackground = (HBRUSH)(COLOR_WINDOW+1);

    wc.lpszMenuName = NULL;

    wc.lpszClassName = g_szClassName;

    wc.hIconSm = LoadIcon(NULL, IDI_APPLICATION);

    if(!RegisterClassEx(&wc)) {

    MessageBox(NULL, "Window Registration Failed!", "Error!",

    MB_ICONEXCLAMATION | MB_OK);

    return 0;

    }

    HWND dialog = CreateDialog(hInstance, MAKEINTRESOURCE(IDD_LOGIN), NULL, MenuDialogProc);

    if(GetLastError() != 0) {

    char error[256];

    sprintf(error, "Error creating logon window: %d", GetLastError());

    MessageBox(NULL, error, "Error", MB_OK);

    return 0;

    }

     

     

    Sunday, September 02, 2007 4:48 PM
  • If you wonder where the error comes from, you can always set a watchpoint on the thread's last error code. That's not for the faint-of-heart, though. Basically, you get the address of thread error code by a given offset from the TEB - take a look at @TEB (or maybe @TIB?) and at the disassembly of GetLastError.

     

    I guess, most Windows APIs would use SetLastError, so you have a less arcane option. You can set a conditional breakpoint on SetLastError, too.

     

    E.g. Debug->Break at Function ..,->Function : {,,kernel32.dll}_SetLastError@4

    Breakpoint Window->Context Menu->Condition: ((int*)@esp)[1]==-21470...

     

    Note that this assumes, x86. {,,kernel32.dll} Set the evaluation context to kernel32.dll, which means symbols for kernel32.dll (make sure you grab public symbols from symbol server!). I.e. the debugger will look in kernel32.pdb to find the given function.

     

    @esp is the stack pointer. The DWORD value at @esp is the return address (i.e. the address pushed by the call) and directly above it (stack grows downward in x86!) is the single argument to SetLastError. That means the breakpoint fires whenever SetLastError(-21470..) is called.

     

    Chances are, it's set somewhere in the DialogProc (e.g. for something called from WM_INITIDIALOG handling).

     

    That said, I believe so long as CreateDialog returns non-null, there's no error.

     

    -hg

    Sunday, September 02, 2007 7:24 PM
  • Okay, That was very helpful and have found an interesting problem.

     

    After using trial and error I finally found that my Progress Bar that I added to my application was causing the error. On Vista with VS2005, it works fine, on XP with VS2005, it works fine. Moving that application with this control to a plain install with no VS2005 shows the error creating the dialog.

     

    What can I do about this? I currently include the Common Controls file in my manifest using:

     

    #pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")

    #pragma comment(lib, "comctl32.lib")

     

    EDIT:

     

    Okay, I finally installed a quick client check to load comctl32.dll and called DllGetVersion which returns that it does not have version 6 installed on the client PC. Which update can I provide which holds this?

    Monday, September 03, 2007 6:05 PM
  • Can you show us the callstack for the SetLastError call with the symbols from Microsoft's public symbol server?

     

    XP ships with Common Controls v6. Are you sure your EXE actually includes a manifest? You can open it with the resource editor (file->open file->Open WIth ->Resource Editor) and verify that there is a resource of type RT_MANIFEST with ID 1 and that it has an the dependency on v6 comctl32.

     

    If there is no manifest, XP would by default bind to Comctl32 v5.81, which would be used to resolve standard ways to get the DllGetVersion entry point.

     

    v6 specific styles on controls embedded in the dialog might actually cause DialogBox to fail as the creation of the control probably fails.

     

    -hg

     

    Monday, September 03, 2007 6:39 PM
  • Okay, I believe the bug is due to duplicate ID's being used within the resource yet it doesn't say they are being used twice. I will edit the IDs and reply with results.

     

    Monday, September 03, 2007 7:10 PM