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?
Related
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;
}
Apologies for any foolish mistakes I've made in my code - I'm new to DCOM and VC++ as a whole. I know the basics but unfortunately not enough to figure this out.
Currently, I have some VC++ code that calls the equivalent of this in Powershell
$excel = [activator]::CreateInstance([type]::GetTypeFromProgID("Excel.Application", "127.0.0.1")); $excel.RegisterXLL("Path\to\x64\dll.dll"). Now if i use this PS Snippet on both x86 Powershell and x64 Powershell targeting an x64 COM server, it, well, suprinsingly works.
I then tried replicating it in C++, and got this far. For clarification, SimpleDLL is a extremely simple DLL that calls WinExec() in DLLmain and pops a calculator App.
https://gist.githubusercontent.com/realoriginal/4178718ee114e3e23c5ebe4651763044/raw/425ce397ed4788c9fac25ae39dcfe1db779c8d99/source.c
This code works fine if the server is x64 and its compiled as an x64 binary. Additionally, it also works if the server is x86 and the binary is compiled to x86.
The problems start arising if I target an x64 server with an x86 binary. I tried using CLSCTX_ACTIVATE_32_BIT_SERVER but that doesnt work at all, as the method is only available in x64.
On the other hand, if I keep it as it is, it sometimes works. To explain what I mean by sometimes, here are my results that I get from it x86 client targeting an x64 Windows server calling this method.
The client triggers an ACCESS VIOLATION with 0x000001 (no idea why)
The client errors at CoCreateInstanceEx() with 0x8007000E: Not enough storage is available to complete this operation.
It loads the x64 DLL and pops the calculator on the remote server
My question is, what could be causing it to fail in those instances that it did, and how could I make it work 100% of the time with x86 client towards x64 COM+ Windows Server?
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
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
Does anyone know of any issues with the ILClone() function on Windows 2000? Is it fully supported? MSDN says it runs on Windows 2000 but I have a user reporting that my program will not run on Windows 2000 because of that function.
EDIT: I was able to get a hold of a Win2K system and I can confirm the issue.
Shell32.dll version installed is 5.0.3700.6705. The error message shown when running the program is: The procedure entry point ILClone could not be located in the dynamic link library SHELL32.DLL
iirc ILClone was available on Windows 5, but it was exported from shlwapi.dll, so you had to load it using LoadLibrary & GetProcAddress() to be compatible.