GUI application Execution fails after porting an application from VS2015 to VS2022.

Sai Krishna 0

There is a GUI Application that is based on C++ that we are trying to update from VS2015 to VS2022. The application after the upgrade is not functioning as expected. The executable does not even open although the build is successful. In VS2015 though, the build is working perfectly on the expected lines.

While trying to debug the code with the VS Debugger goes through the following function :

int __cdecl TestStartup()
{
  return WinMainCRTStartup();
}
int

WinMainCrtStartup() is supposed to call a function called WinMain(). During this stage simultaneously on the Visual Studio debugger, its showing that its trying to load a set of DLLs before breaking. We could observe a difference in the working VS2015 vs the non functioning VS2022 on the list of DLLs that is loaded from C:\Windows\System32 shown on Output Section in VS Debugger

VS2015 :

Ntdll.dll, kernel32.dll, KernelBase.dll, gdi32.dll, win32u.dll, gdi32full.dll, msvcp_win.dll, ucrtbase.dll , user32.dll, advapi32.dll, msvcrt.dll, sechost.dll, bcrypt.dll, rpcrt4.dll, shell32.dll, psapi.dll , winmm.dll , wininet.dll, imm32.dll, Uxtheme.dll, Combase.dll, Kernel.appcore.dll, Ole32.dll, Comctl32.dll, oleaut32.dll, shlwapi.dll, bcryptprimitives.dll, windows.storage.dll, WinTypes.dll, SHCore.dll, cmedit64d.dll, GdiPlus.dll, msctf.dll, TextShaping.dll, TextInputFramework.dll , CoreMessaging.dll, CoreUIComponents.dll, Cryptbase.dll, AudioSes.dll, winmmbase.dll , MMDevAPI.dll, avrt.dll, ksuser.dll, devobj.dll, cfgmgr32.dll, cfgmgr32.dll, msacm32.dll, midimap.dll, clbcatq.dll, powrprof.dll, umpdc.dll, ResourcePolicyClient.dll

VS2022 :

Ntdll.dll, kernel32.dll, KernelBase.dll, gdi32.dll, win32u.dll, gdi32full.dll, msvcp_win.dll, ucrtbase.dll , user32.dll, advapi32.dll, msvcrt.dll, sechost.dll, bcrypt.dll, rpcrt4.dll, shell32.dll, psapi.dll , winmm.dll , wininet.dll, imm32.dll

We are trying to fix this issue while updating to VS2022. Tried checking various project configurations but unable to figure out a specific reason for this issue.

Note: The same application is built and executed successfully with console.
If any issues with specific versions related to visual studio and its dll's can be notified.

RLWA32 46,376 Reputation points

2025-01-06T07:03:07.1133333+00:00

It would be helpful if you provided some detail information about the point of failure such as error codes, error message text, call stack and so forth.

I also suggest you use gflags.exe to Show loader snaps. This will produce output in the debugger that will help you identify any dll load failures that could cause the application to terminate. This is installed as part of the Windows SDK and should be available through the start menu. Make sure to use the "Image" tab to show loader snaps only for your specific process.

An example of what this looks like -
Sai Krishna 0 Reputation points

2025-01-06T09:52:03.44+00:00

In VS2022 {17.11.5}: Point of failure is, when the GUI executable is ran, no response is seen, when ran using the debugger, then as mentioned above, when the WinMainCrtStartup() starts, it starts loading certain dlls's and after imm32.dll there is no specific error, but the execution starts failing.

In VS2015 with win SDK 8.1: Same code path is run and after imm32.dll, other dll's like Uxtheme.dll, Combase.dll, Kernel.appcore.dll, Ole32.dll, Comctl32.dll, oleaut32.dll, shlwapi.dll, bcryptprimitives.dll, windows.storage.dll, WinTypes.dll, SHCore.dll, cmedit64d.dll, GdiPlus.dll, msctf.dll, TextShaping.dll, TextInputFramework.dll , CoreMessaging.dll, CoreUIComponents.dll, Cryptbase.dll, AudioSes.dll, winmmbase.dll , MMDevAPI.dll, avrt.dll, ksuser.dll, devobj.dll, cfgmgr32.dll, cfgmgr32.dll, msacm32.dll, midimap.dll, clbcatq.dll, powrprof.dll, umpdc.dll, ResourcePolicyClient.dll are loaded successfully and execution is passed to WinMain() which is contradictory in the VS2022 setup.

RLWA32 46,376

I could not reproduce your issue with VS2022 17.12.3 with a basic Win32 desktop application.

This is the code that I tested with that compiles for either unicode or non-unicode builds-

// WinRawEntryTest.cpp : Defines the entry point for the application.
//

#include "framework.h"
#include "WinRawEntryTest.h"

#define MAX_LOADSTRING 100

// Global Variables:
HINSTANCE hInst;                                // current instance
TCHAR szTitle[MAX_LOADSTRING];                  // The title bar text
TCHAR szWindowClass[MAX_LOADSTRING];            // the main window class name

// Forward declarations of functions included in this code module:
ATOM                MyRegisterClass(HINSTANCE hInstance);
BOOL                InitInstance(HINSTANCE, int);
LRESULT CALLBACK    WndProc(HWND, UINT, WPARAM, LPARAM);
INT_PTR CALLBACK    About(HWND, UINT, WPARAM, LPARAM);

#ifdef UNICODE
extern "C" int __cdecl wWinMainCRTStartup();
#else
extern "C" int __cdecl WinMainCRTStartup();
#endif

DWORD  __stdcall RawEntry()
{
#ifdef UNICODE
    return wWinMainCRTStartup();
#else
    return WinMainCRTStartup();
#endif
}

int APIENTRY _tWinMain(_In_ HINSTANCE hInstance,
                     _In_opt_ HINSTANCE hPrevInstance,
                     _In_ LPTSTR    lpCmdLine,
                     _In_ int       nCmdShow)
{
    UNREFERENCED_PARAMETER(hPrevInstance);
    UNREFERENCED_PARAMETER(lpCmdLine);

    // TODO: Place code here.

    // Initialize global strings
    LoadString(hInstance, IDS_APP_TITLE, szTitle, MAX_LOADSTRING);
    LoadString(hInstance, IDC_WINRAWENTRYTEST, szWindowClass, MAX_LOADSTRING);
    MyRegisterClass(hInstance);

    // Perform application initialization:
    if (!InitInstance (hInstance, nCmdShow))
    {
        return FALSE;
    }

    HACCEL hAccelTable = LoadAccelerators(hInstance, MAKEINTRESOURCE(IDC_WINRAWENTRYTEST));

    MSG msg;

    // Main message loop:
    while (GetMessage(&msg, nullptr, 0, 0))
    {
        if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
        {
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        }
    }

    return (int) msg.wParam;
}



//
//  FUNCTION: MyRegisterClass()
//
//  PURPOSE: Registers the window class.
//
ATOM MyRegisterClass(HINSTANCE hInstance)
{
    WNDCLASSEX wcex;

    wcex.cbSize = sizeof(WNDCLASSEX);

    wcex.style          = CS_HREDRAW | CS_VREDRAW;
    wcex.lpfnWndProc    = WndProc;
    wcex.cbClsExtra     = 0;
    wcex.cbWndExtra     = 0;
    wcex.hInstance      = hInstance;
    wcex.hIcon          = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_WINRAWENTRYTEST));
    wcex.hCursor        = LoadCursor(nullptr, IDC_ARROW);
    wcex.hbrBackground  = (HBRUSH)(COLOR_WINDOW+1);
    wcex.lpszMenuName   = MAKEINTRESOURCE(IDC_WINRAWENTRYTEST);
    wcex.lpszClassName  = szWindowClass;
    wcex.hIconSm        = LoadIcon(wcex.hInstance, MAKEINTRESOURCE(IDI_SMALL));

    return RegisterClassEx(&wcex);
}

//
//   FUNCTION: InitInstance(HINSTANCE, int)
//
//   PURPOSE: Saves instance handle and creates main window
//
//   COMMENTS:
//
//        In this function, we save the instance handle in a global variable and
//        create and display the main program window.
//
BOOL InitInstance(HINSTANCE hInstance, int nCmdShow)
{
   hInst = hInstance; // Store instance handle in our global variable

   HWND hWnd = CreateWindow(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW,
      CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, nullptr, nullptr, hInstance, nullptr);

   if (!hWnd)
   {
      return FALSE;
   }

   ShowWindow(hWnd, nCmdShow);
   UpdateWindow(hWnd);

   return TRUE;
}

//
//  FUNCTION: WndProc(HWND, UINT, WPARAM, LPARAM)
//
//  PURPOSE: Processes messages for the main window.
//
//  WM_COMMAND  - process the application menu
//  WM_PAINT    - Paint the main window
//  WM_DESTROY  - post a quit message and return
//
//
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    switch (message)
    {
    case WM_COMMAND:
        {
            int wmId = LOWORD(wParam);
            // Parse the menu selections:
            switch (wmId)
            {
            case IDM_ABOUT:
                DialogBox(hInst, MAKEINTRESOURCE(IDD_ABOUTBOX), hWnd, About);
                break;
            case IDM_EXIT:
                DestroyWindow(hWnd);
                break;
            default:
                return DefWindowProc(hWnd, message, wParam, lParam);
            }
        }
        break;
    case WM_PAINT:
        {
            PAINTSTRUCT ps;
            HDC hdc = BeginPaint(hWnd, &ps);
            // TODO: Add any drawing code that uses hdc here...
            EndPaint(hWnd, &ps);
        }
        break;
    case WM_DESTROY:
        PostQuitMessage(0);
        break;
    default:
        return DefWindowProc(hWnd, message, wParam, lParam);
    }
    return 0;
}

// Message handler for about box.
INT_PTR CALLBACK About(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
    UNREFERENCED_PARAMETER(lParam);
    switch (message)
    {
    case WM_INITDIALOG:
        return (INT_PTR)TRUE;

    case WM_COMMAND:
        if (LOWORD(wParam) == IDOK || LOWORD(wParam) == IDCANCEL)
        {
            EndDialog(hDlg, LOWORD(wParam));
            return (INT_PTR)TRUE;
        }
        break;
    }
    return (INT_PTR)FALSE;
}

The linker properties for all Platform/Configuration combinations were set as follows to specify the entry point function -

Rawentry

Sai Krishna 0 Reputation points

2025-01-06T11:25:56.4+00:00

Ok sure will check this application with the version and will try to follow the platform/configurations for the entry point on our end. Thanks for your response.
Minxin Yu 12,351 Reputation points Microsoft Vendor

2025-01-09T01:11:09.22+00:00

Hope you've been well. Is your problem solved?
Sai Krishna 0 Reputation points

2025-01-09T11:19:01.4866667+00:00

Issue with the application is not resolved, the application we are testing is using WinMainCRTStartup() and WinMain instead of wWinMainCRTStartup(), wWinMain. Observed in certain links that, setting the Character set to Multi-Byte Character Set which is part of configuration properties of the project, will ensure the flow to be using WinMain, updated the same in the DemoApp, the gui works fine. Similar change has been done in the application we are trying to run, build is successful but when the binary is tried to run, there is no output/response. Issue still persists. Note: By default no character set is enabled and the code flow goes through the WinMain() in our test application.
Comparison of configuration parameters with the DemoApp and our TestApp:

Difference in lib file: comctl32.lib is present in our test application

When executing the binaries with dependency walker observed the following differences:

TestApp:

-API-MS-WIN-CORE-PSAPI-OBSOLETE-L1-1-0.DLL

-c:\windows\system32\PSAPI.DLL

Demoapp:

-API-MS-WIN-CORE-PSM-KEY-L1-1-1.DLL

-c:\windows\system32\KERNEL.APPCORE.DLL

-c:\windows\system32\VCRUNTIME140.DLL

-c:\windows\system32\WINTYPES.DLL

-c:\windows\winsxs\amd64_microsoft.windows.common controls_6595b64144ccf1df_5.82.22621.3527_none_b43b7f4b638cc64f\COMCTL32.DLL

-EXT-MS-WIN-FAMILYSAFETY-CHILDACCOUNT-L1-1-0.DLL

-EXT-MS-WIN-HOSTACTIVITYMANAGER-HOSTIDSTORE-L1-1-0.DLL

-EXT-MS-WIN-ROMETADATA-DISPENSER-L1-1-0.DLL
RLWA32 46,376 Reputation points

2025-01-09T11:45:04.12+00:00

You might consider running your application underneath the Application Verifier to see if it highlights any issues. Also, using Sysinternals process monitor may also give you some additional insight.
Sai Krishna 0 Reputation points

2025-01-09T15:05:22.7566667+00:00

Can you share more details on the application verifier if possible?
Will check with these items, thanks
Sai Krishna 0 Reputation points

2025-01-09T15:33:59.4733333+00:00

https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/application-verifier this should help right?
RLWA32 46,376 Reputation points

2025-01-09T15:45:07.73+00:00

You can install the Applicatin Verifier through the Windows SDK. Since there is very little visibility into the details of your problematic application its not possible to predict whether or not it will reveal the root cause of your problem. But its certainly worth a try.

Share via

GUI application Execution fails after porting an application from VS2015 to VS2022.

Your answer