0

I created a new C++ MFC MDI Application in Visual Studio.

FIRST PROBLEM - The exception An invalid handle was specified is thrown when launching it in Debug/Release (x86 only).

Here is my config. :

  • Visual Studio Pro 2015 Version 14.0.25431.01 Update 3
  • Windows 10 Version 1809 (OS Build 17763.292)
  • .NET Framework Version 4.7.03190
  • Visual C++ Redistributable installed (2005, 2008, 2010, 2012, 2013, 2015)

Pressing "Break" : Without Microsoft Symbol Servers, it shows something went wrong in C:\Windows\SysWOW64\ntdll.dll. With Microsoft Symbol Servers, it just shows "Source Not Available".

Pressing "Continue" one or two times : Launches the application, which can be used normally.

When exiting the app by clicking on the dialog "X" button, an Access violation reading location is also thrown in ntdll.dll. This exception is thrown in (x86) AND (x64).

I tested it on 3 others PCs running Windows 10 (older version) and the same thing happens. I tested it on 2 PCs running Windows 7 and there is no problem.

EDIT - Please see the two following screenshots for the call stack after each of these exceptions are thrown.

Callstack for Invalid Handle Exception when launching the app

Callstack for Access Violation Exception when exiting the app

SECOND PROBLEM - The values of initialized variables are randomly wrong.

For example, I have seen this in a base class constructor :

variable = 0; // int

The debugger shows me that variable value is 52685. Not sure if it is a coincidence but the ID of the VC++ 2015 Redistributable Update 3 is 52685 (see URL param).

Microsoft Visual C++ 2015 Redistributable Update 3 / id=52685

The output of variable in the console shows the correct value (0).

I would appreciate to have some help to resolve this issue as it makes debugging really hard. The only thing I am sure is that it is related to Windows 10.

EDIT - Please see the two following screenshots of variables values while debugging. In the first one, you can see that all "int" variables have the value -842150451 (which should be 0 instead, right?). These variables are declared in the private section of a class. The second screenshot shows the default constructor of this class. One of these "int" (image_bpp) shows the value 52685 instead of the assigned 0. If I switch the initialization of image_bpp and image_pixel_color, then it is the image_pixel_color that shows the wrong value.

Declared variables values

Initialized variables values

Looks like I am not the first one with this issue. I forgot to mention that I am using a simple inheritance (instanciating a derived class, then the constructor of the base class is called and this is where I put my breakpoint).

See this link for reference : Compiler bug with derived classes

Vingeance
  • 17
  • 3
  • You say this is a new empty application. Is it MFC dialog based application? or is it SDI, MDI etc.? – Barmak Shemirani Feb 06 '19 at 01:57
  • It is a MDI application. After selecting MFC, the wizard is shown and I let the default settings. I will try again tomorrow to see if it happens with all types of MFC apps. – Vingeance Feb 06 '19 at 03:18
  • Try "Use MFC in a static library" in the "Use of MFC" setting in the first wizard page. – Jabberwocky Feb 06 '19 at 07:14
  • Tried MFC (SDI, MDI, Dialog Based) static and dynamic - same problem. Also tried Win32 Application (Windows application) - same problem. The only application that does not throw these exceptions is a Console App. – Vingeance Feb 06 '19 at 14:19
  • 1
    I have the exact Windows 10 Version, using VS 2017 community version, can't duplicate the error. Maybe you have a weird anti-virus program installed on some systems? Otherwise upload a small project to some website so we can see. – Barmak Shemirani Feb 06 '19 at 18:20
  • I do have an antivirus installed (Norton Symantec). I disabled it along with the firewall but still having the issue. The antivirus is also installed on some Windows 7 computers which are not experiencing the problem. Transfering the project sources to a Windows 7 PC and running the app on the same version of Visual Studio cause no issue. I could probably try a VS 2017 trial version. – Vingeance Feb 06 '19 at 23:16
  • Does the "initialized variables are wrong" - problem occur in both debug and release builds? In release builds that is expected to happen, since the variable may e.g. be placed in a CPU register that is then reused for something else. If it only happens in debug code, you can further disable optimizations in release mode to see if it gets fixed. – Sami Sallinen Feb 07 '19 at 12:48
  • Please see the two screenshots of variables values while debugging. In the first one, you can see that all "int" variables have the value -842150451 (which should be 0 instead, right?). These variables are declared in the private section of a class. The second screenshot shows the default constructor of this class. One of these "int" (image_bpp) shows the value 52685 instead of the assigned 0. If I switch the initialization of image_bpp and image_pixel_color, then it is the image_pixel_color that shows the wrong value. – Vingeance Feb 07 '19 at 15:16
  • @SamiSallinen Only happens while debugging in Visual Studio. The right value is assigned (because a print of the variable displays the correct value). Only the value shown in "Locals" section or by leaving my mouse on a variable are sometimes wrong. Running the build outside of VS looks fine. – Vingeance Feb 07 '19 at 15:22
  • @BarmakShemirani I would like to know if you got a "Target Platform Version" set in the project general properties, and which "Platform Toolset" you use. It looks like my default "Target Platform Version" is Windows 8.1 and the "Platform Toolset" is Visual Studio 2015 (v140). – Vingeance Feb 07 '19 at 15:22
  • What does the stack trace window show? In Debug mode you should see the exception and be able to bring up the stack window to see which of your functions is creating the environment for the exception. At that point you should be able to inspect variables. – Richard Chambers Feb 07 '19 at 15:26
  • @RichardChambers Please see the two screenshots I have uploaded for problem #1. I can't inspect variables since the exception is thrown in a Microsoft DLL (ntdll). – Vingeance Feb 07 '19 at 16:05
  • What I see are screen shots of local variable dumps not the stack trace. My question is where in your code is the call that results in the call into the ntdll with a bad handle. I'm curious if the stack is good or if there is something that is overwriting memory. I'm curious what call is triggering the exception. If everything is good then you should be able to see the complete call stack and see which function within your code is invoking the Microsoft functionality which is reporting the bad handle. – Richard Chambers Feb 07 '19 at 16:26
  • @RichardChambers You are not opening the right screenshots. I edited my post to divide it in two separate problems in bold, which I originally thought were linked. Please refer to the first problem and sorry for the confusion. – Vingeance Feb 07 '19 at 16:56
  • @WernerHenze Someone asked me to show the stack trace. Thanks for the downvote. – Vingeance Feb 07 '19 at 16:59
  • @Vincent-SimonBolduc Did you follow the link and read the page? I am not downvoting for the stack trace but for the images. Why? Read the page, it's all described there. – Werner Henze Feb 07 '19 at 17:03
  • The "incorrectly initialized variables" seem to be uninitialized memory. The visual studio debug runtime initializes all allocated memory to the hex byte 0xCD = 205 decimal. In an int with all bytes 0xcd, you get the value -842150451. (The point of such initialization is to make it easier to detect the use of uninitialized variables.) – Sami Sallinen Feb 07 '19 at 17:33
  • I used *Target platform Windows 10 + highest SDK version + Platform Toolset Visual Studio 2017 (v140)*, but doubtful it makes a difference here. – Barmak Shemirani Feb 07 '19 at 18:02
  • 1
    @BarmakShemirani You are right. Tried to build with Windows 10 latest SDK, still have the issue. Thanks for your help though. – Vingeance Feb 07 '19 at 20:34
  • @WernerHenze I did read the page you linked. However, there seems to be no way to see more details than what is shown on my images. – Vingeance Feb 07 '19 at 20:37

0 Answers0