Visual Studio 2013 Express MFC program could not work after Windows 10 update to 1903 - visual-studio-2013

These days I upgrade to Windows 10 to 1903, however, after that, my MFC program soon disappears after running up. The solution is composed of an MFC project and a DLL project, they are static linked.

Thank you all for paying attention to my question. So far the issue disappear, and below is the story.
1) I modified my code to dynamic link.
2) I got the message of System AccessViolationException when calling the second API of DLL.
3) I found think link. Programs randomly getting System.AccessViolationException
4) In the post, someone mentioned that change platform setting may solve it
5) So I change my platform setting to x64
6) It works
7) I continue to finish my work base on x64 and everything looks OK
8) However I was required to provide x32 version Orz
9) So I have to dig this question as very first priority
10) However, base on the modified source code, now x32 is able to run
Sorry there is not so many useful information.....

There is more information.
I tried to install VS2013 Express at another Win7 64bit PC, which is able to re-produce the phenomenon. It does not matter x86 or Win32 this time.
When Running "Local Windows Debugger," (or use hostkey of: F10, F11, F5)
the debug interface soon finish, with below log:
The program '[2576] test.exe: Native' has exited with code 1 (0x1).
However, in my code did not write any pattern like "return 1"
Below is the main function built-in
[STAThreadAttribute]
int main(array<System::String ^> ^args)
{
// Enabling Windows XP visual effects before any controls are created
Application::EnableVisualStyles();
Application::SetCompatibleTextRenderingDefault(false);
// Create the main window and run it
Application::Run(gcnew Form_main());
return 0;
}

Related

Windows IOCP socket programming crash in windows 10 & 2012

I am trying to help one of my customer to migrate a very old vc++ program which works on Windows 2003 as a win32 service to x64. It was compiled with VC 2005.
I have migrated to VC 2019 with windows SDK 10 & Windows 10.
There were few minor issues in DB and windows service ATL. I was able to fix them all.
Now there is a strange issue with the IOCP wherein the GetQueuedCompletionStatus results in success but the psobSockInfo and PerIoData results in unable to read error. (attached to the process in vs 2019 in debug mode).
bResult = GetQueuedCompletionStatus(sobIocpThParam->hReqRecThread,&BytesTransferred,(PDWORD_PTR)&psobSockInfo,(LPOVERLAPPED *) &PerIoData,INFINITE);
The code is written very similarly to this example and the header file in line with
I have tried to zero both the memory, tried to set the pointers to NULL. Nothing has helped. The bResult is 1. BytesTransfered is 177, The socket handle is valid.
Can any one point me in the right direction?

Debugging Spawns A Non Terminable Process, and CLI not launching

I've been fighting this little problem for a while now, so I'm really hoping I can get some help. I've been looking for a solution to this, and I found this SO question: Debugging doesn't start.
My issue is somewhat similar to the issue discussed here, except that my issue is a two-parter.
Part 1: Similar to the issue discussed on the other question. (Debug Window Doesn't show up)
When I attempt to launch my Windows 32 console application project (The simple kind that opens in the windows CLI). The CLI (or CMD) window doesn't open, and windows idles giving me a spinning cursor wheel. Visual Studio IDE (I'm using VS 2013 Community) becomes unresponsive and I cannot access any menus, or use any hotkey to "Stop Debugging". One difference from the provided SO question though, is that when I try to launch "MyProject.exe" from my project's "Debug" folder I get the same result as attempting to debug in the IDE.
Part 2: Unkillable Process
When I try to close my debug application in the windows task manager, it is not listed as an ongoing process. However, whenever I try to manipulate, delete, or otherwise modify my Project.exe application (in my Project's "Debug" folder), windows informs me that the application is in use. Confused by this, I downloaded two applications. The first was Process explorer, which showed me that I did in fact have 2 instances of "MyProject.exe" running. The second was Process Hacker, which also showed me 2 instances of "MyProject.exe". However, neither of these programs were able to terminate either of the "MyProject.exe" processes.
I am capable of terminating the processes for visual studio and restarting the IDE, however, because the "MyProject.exe" processes are still running. Building always fails with the error
"Error 1 error LNK1168: cannot open C:\Users\Brandon\Desktop\MyProject\Debug\MyProject.exe for writing"
Whenever I restart my computer, the lock files (as expected) are removed, and the "MyProject.exe" processes disappear. I can restart VS and everything works, but if I try to Debug (pressing "Start Debugging" or F5) the same issue occurs.
A process of my program is started ("MyProject.exe"), but the CLI window where my program's text should appear doesn't show up. Visual studio locks up, and "MyProject.exe" persists until the next restart because "MyProcess.exe" cannot be terminated.
My solution configuration is set to "Debug", Solution Platforms = Win32.
I have tried creating a new blank console project in VS 2013 and I get the same result: code builds fine, but I have the same debugging issue. I get an identical result with a quickly assembled "Hello World" project.
Sorry for being a noob, but honestly. I really don't know what's going on, so any help is greatly appreciated.
(Note: Running Windows 10 with VS2013)
EDIT (UPDATE):
So, I'm having the same problem with several programs in Windows 10 (most notably Allegorithmic's Substance Painter). So it looks like this may actually be an OS problem. Several of my programs whenever I try to launch them do the same thing...the program acts like it's going to launch, but then no usable window appears. Looking at my processes I can see that the process has been started, but it is once again unkillable. For reference, I am using Windows 10 Version 1511 (OS Build 10586.17).
I believe your problem might be Avast, if you are running it. I had exactly the same issues until I uninstalled it. Had upgraded to Win10 and VS2013 just froze, same as you described.
Cheers.

Executable Valid on Win7 and On WinXP professional SP3 "not a valid Win32 application (193)"

I have an executable compiled by MSVS2013 on Windows 7 SP1 32 bit with C runtime statically linked and platform toolset "Visual Studio 2013 - Windows XP (v120_xp)"
It runs perfectly on Win7 (see attached screenshot of Dependency Walker profiling).
It fails to run on WinXP:
Here is the profile log:
Starting profile on 12/9/2014 at 2:55:03 AM
Operating System: Microsoft Windows XP Professional (32-bit), version 5.01.2600 Service Pack 3
Program Executable: c:\temp\OCTOPUS.EXE
Program Arguments:
Starting Directory: C:\Temp\
Search Path: C:\Program Files\ActiveState Komodo Edit 8\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\MATLAB\R2009b\runtime\win32;C:\Program Files\MATLAB\R2009b\bin;C:\VisaPoint\sbperl\perl\bin
Options Selected:
Simulate ShellExecute by inserting any App Paths directories into the PATH environment variable.
Log DllMain calls for process attach and process detach messages.
Log DllMain calls for all other messages, including thread attach and thread detach.
Hook the process to gather more detailed dependency information.
Log LoadLibrary function calls.
Log GetProcAddress function calls.
Log thread information.
Use simple thread numbers instead of actual thread IDs.
Log first chance exceptions.
Log debug output messages.
Use full paths when logging file names.
Log a time stamp with each line of log.
Automatically open and profile child processes.
--------------------------------------------------------------------------------
00:00:00.000: Failure starting the process. %1 is not a valid Win32 application (193).
[1]: http://i.stack.imgur.com/m82n6.png
[2]: http://i.stack.imgur.com/6Yr37.png
Modern versions of Visual Studio, starting with VS2012, use linker settings that marks the executable image compatible with the current generation of Windows. Version 6, started with Vista. XP and Server2003 were in the previous generation, version 5.
You can still build programs that run on XP with VS2013. But you have to make a setting change. Right-click the project, Properties, General. Change the Platform Toolset setting to v120_xp.
There are a few consequences, your program gets built with an old version of the Windows SDK. V7.1, the last one that was still compatible with XP. The C runtime library makes a bunch of operating system calls that are only available in generation 6. It will stumble along without them, affecting relatively minor details related to threading and culture. This is the kind of FUD that ought to remind you that it might not be the best idea to still promise support for such an ancient operating system. Make sure you keep a running version of XP around so you can properly test and repro. And keep in mind that you can't install VS on it anymore so if you do get a support call from an XP user then you tend to get a fairly heavy migraine.
Ok, just forgot to set SUBSYSTEM in Linker options.
Here is a link with explanations:
https://software.intel.com/en-us/articles/linking-applications-using-visual-studio-2012-to-run-on-windows-xp

Programmatic data breakpoint in Visual Studio 2010

I've been trying to use programmatic data breakpoints, à la the CBreakpoint example, by using SetThreadContext to set the debug register directly. Most references that I can find indicate the Visual Studio will still break whenever it encounters a data breakpoint, even if it didn't set that data breakpoint itself. However, this doesn't appear to be how Visual Studio 2010 works.
I'm in a situation where my data breakpoint works perfectly when the program is not being debugged (it crashes with STATUS_SINGLE_STEP, which is the exception raised by a data breakpoint). It also breaks properly if I'm debugging with WinDbg. But when debugging it under either Visual Studio 2010, it seems to just keep trucking and ignore the breakpoint. Does anyone have any experience with using a programmatically-set data breakpoint under Visual Studio 2010, under Windows 7? Is there something that I need to do to it them to break? (I tried adding STATUS_SINGLE_STEP to the 'first-chance exceptions' list, with no change in behavior.)
Alternately, is there anything that I might be doing to swallow the STATUS_SINGLE_STEP exception in the debugger? Would a structured exception handler eat the exception before the debugger can see it? Is anything affected by the fact that this is a x86_64 program? Is there some dance I need to do in the Visual Studio 2010 settings?
Did a little testing, got VS 2010 SP1 Ultimate on win7 x64, using a 32bit binary to break correctly on HW breakpoints (both with and without SEH). When using a 64 bit binary however, it doesn't trap the single step (and I had to alter a few types just to get it to compile).
Digging a little deeper, it seems to be VS acting weird, cause although it doesn't trap the single step, I can't get it to correctly step over a section of code that will trigger a HW breakpoint.
I have a feeling that the library isn't correctly setting the DR registers under x64, this may be to do changes in SetThreadContext for x64.
Update
Fiddling around a little more, I noticed that the library you are using doesn't suspend the thread before setting or getting the thread context, MSDN says this is a big NO-NO:
You cannot get a valid context for a running thread. Use the SuspendThread function to suspend the thread before calling GetThreadContext.
However, even using another library that does correctly suspend the target thread and executes all its calls without error still doesn't let VS trap the BP, which makes me think that not only is the library you are using buggy, but VS' x64 debugger is buggy as well.
Have you enabled mixed (native & managed) debugging for your project?
I went to project properties->configuration properties->debugger->debug type set to "mixed"
found this answer here:
https://social.msdn.microsoft.com/Forums/windowsserver/en-US/47ebd835-e538-4ff6-8c91-df45bd46d548/vc-express-2012-x64-clr-breakpoint-not-hit-no-executable-associated-static-library?forum=windbg
There is a function named DebugBreak() that you can use to programmatically break your execution under MSVC 2010 but it stop inside of DebugBreak( disassembly code ). So if you want to break just in your code use __asm int 3 this is very simple and work in all intel compatible CPUs.
And one other note use IsDebuggerPresent() before either of DebugBreak() or __asm int 3 to avoid error in runtime( of course you already know that! :) )

Destroy process-less console windows left by Visual Studio debug sessions

A known bug with a Windows XP security update KB978037 can occur with Visual Studio 2005 (and 2008) where sometimes if you restart a debugging session on a console app then the console window doesn't get closed even though the owner process no longer exists. The problem is discussed further here:
Visual studio debug console sometimes stays open and is impossible to close
These zombie windows then can not be closed via the Taskbar or via the TaskManager, and typically require a power off/on to get rid of them. Over the period of even a single day you can accumulate quite a few of them, which clog up your TaskBar and are generally annoying.
I thought I would knock up a simple C++ Win32 utility to attempt to call DestroyWindow() on these windows by passing the windows handle as a cmd-line argument and converting it to a HWND.
I'm converting the handle from a string by parsing it as a DWORD then casting the DWORD to a HWND. This appears to be working as if I call GetWindowInfo() on the handle it succeeds. However calling DestroyWindow() on the handle fails with error 5 (access denied), presumably because the caller process (i.e. my app) doesn't own the window in question.
Any ideas as to how I might get rid of the zombie windows, either via the above approach or any other alternative short of rebooting? I'm in a corporate environment so installing/uninstalling updates/service-packs etc isn't an option.
Microsoft's hot fix for Windows XP and Windows 2003
I know this is not what you want to hear but the only way to get rid of these windows is by rebooting the computer
Apparently the windows team is trying to fix it:
http://blogs.msdn.com/debugger/archive/2010/03/11/help-my-console-windows-won-t-go-away.aspx
but not much seems to be happening
This issue is still a problem with Visual Studio 2010 on Windows 7!
See this thread

Resources