I have a console application. In XP, I can use SetConsoleCtrlHandler() to register a callback that receives CTRL_LOGOFF_EVENT, CTRL_C_EVENT and a few others. It works great. When the callback is called I can cleanup before I return from the call. Problem is, SetConsoleCtrlHanlder() is not supported in Vista. Now what?
SetConsoleCtrlHandler has worked just fine for me on Vista, and there's no indication on its MSDN page that it shouldn't.
Are you having difficulty getting the same code to work on a Vista system? If so, what failure mode / error codes are you seeing?
Related
Thank you for your reply and comments.
Let me describe the situation more detailedly.
I use Visual C++ 2008 to write a small application that will invoke MAPI. I use MAPIStubLibrary to support both 32bit and 64bit MAPI. MAPIStubLibrary can be found at https://msdn.microsoft.com/en-us/library/office/cc963763.aspx#sectionSection2 . It works on other versions of Outlook and most of the systems. However, under Windows 10(32bit) with Office 2016(32bit) installed, when I execute the following statement to initialize MAPI:
MAPIInitialize(NULL);
I will get the above error message "The operating system is not presently configured to run this application". And there will be an unhandled exception raised from the function GetDefaultMapiHandle(), which is in StubUtils.cpp, part of the MAPIStubLibrary.
The exact line that cause the exception is:
hinstMapi = LoadLibraryW(wzPath);
It seems that MAPIStubLibrary is trying to load 32bit MAPI but fails. wzPath is pointing to olmapi32.dll instead of msmapi32.dll.
In the error message, if I click “OK” button in the error messagebox, the application will continue running without problems. However, the error message is still frustrating and confusing the users. Therefore, how to eliminate the error?
Thank you very much.
This usually happens when you are either loading a wrong MAPI dll (e.g. olmapi32.dll instead of msmapi32.dll) or if your app is running in the compatibility mode (do you include a manifest?) and the MAPI system ends up patching wrong Windows API functions assuming an older version of Windows.
In my application, I am using the following Win32 API to before loading the mapi32.dll.
win32 API: ::GetProfileInt(_T("MAIL"), _T("MAPI"), 0);
This API is consistently failing on Windows 8.1 Italian 64-Bit PC.
But, this API is succeeding on all other PCs like Windows 8.1 English(US) 64-Bit PC, Windows 8.1 Japanese 64-Bit PC.
Kindly provide your kind help for fixing the above issue.
To find MAPI32.dll look in either of these paths:
C:\Windows\SysWOW64\mapi32.dll
C:\Windows\System32\mapi32.dll
or use this
GetWindowsDirectory(buf, 260);
lstrcat(buf, TEXT("\\SysWOW64\\mapi32.dll"));
...
To access old win.ini settings, look in this registry key:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\win.ini
But there is probably nothing there about MAPI, it's about 20 years out of date.
The code you originally got this from was probably very old and is no longer supported. If you read the documentation for GetProfileInt, you'll see that its purpose is to support 16-bit applications.
I recommend removing the call. I have also observed it failing on Windows 7 machines while succeeding on Windows 10 machines. I think the more appropriate calls are to use SearchPath(nullptr, L"MAPI32.DLL", nullptr, 0, nullptr, nullptr) to see if MAPI32.DLL would even be found. An alternative is to just attempt the LoadLibrary(L"MAPI32.DLL") and check the returned handle.
An even better solution might be to change your code to call MAPISendMailHelper as it will do the LoadLibrary, GetProcAddress, etc. for you.
I'm working with a DirectX 11 program on Windows 8 for which I Think there is a problem with the vertex shader. I tried to start DirectX diagnostic mode ([Alt]+[F5]) and while the program will normally run without throwing an exception if diagnostic mode is turned on it will always crash at the call to "CreateSwapChainForHwnd" with the following error message
Unhandled exception at 0x0097C004 in MyApplication.exe: 0xC0000096:
Privileged instruction.
Does DirectX debugging simply not work for Windows Storeapplications? It seems to work fine in specific Win32 application scenarios, but I seem to be encountering many scenarios where it doesn't work.
Update:
Among other things I installed the DirectX debugging symbols and got a marginally more detailed message.
Unhandled exception at 0x000007FDED063589 (dxgi.dll) in
MyApplication.exe: 0xC0000005: Access violation reading location
0x0000000000000000.
So it looks to be a null reference exception from the code on Microsoft's end.
I think your problem is that the debugger doesn't like CreateSwapChainForHwnd(), as this other guy found out: Requirements for target application for Visual Studio 11's Graphics Debugger
My code calls D3D11CreateDevice() followed by IDXGIFactory::CreateSwapChain() and the debugger works for desktop win32 apps, so try that.
What are the specific Windows Store application scenarios that you got it to work in? I have the exact opposite problem - I cant get Alt-F5 debugger to work at all for windows store apps, but it works for desktop win32 apps.
I know that protected process are all about protection and entirely made for blocking me doing so, but I've got a problem.
My problem is as follows:
I'm building a security tool that should, between other stuff, block some services from being launched/stopped etc.
The way I've did so is to hooking "services.exe" and detouring RStartService function. It worked perfectly on windows XP SP3.
But of course, It doesn't work on my windows 7 machine. I'm assuming the problem is the "protected processes" mechanism.
Is there a way to bypass this protection? (sign my application or something?)
The problem was NOT protected processes, but a problem with the injector.
Since Windows Vista, the interactive applications areno longer running in "session 0" while "services.exe" does run in "session 0".
Cross sessions hooking is blocked since the big bang (or windows xp, I'm not sure which came first). It would be like a trying to hook a software on a different "remote desktop" session.
My injector was a console application, meaning it ran in in the interactive applications session which is why I got ERROR_ACCESS_DENIED .
A quick workaround will be to convert the injector into service, because services runs in "session 0".
In the second example (in the section examples) on this link, there is a description on using WM_QUERYENDSESSION to abort a shutdown. It also states that this does not work on versions of windows later than XP. This is conflicting with the advice given on another question here at stackoverflow. What is the correct answer? I do not have a computer with either so I am unable to test.
Some applications got the WM_QUERYENDSESSION handling wrong (Not passing to DefWindowProc, they incorrectly returned 0 even though they did not intend to block shutdown) and so MS changed it with Vista, you now need to call ShutdownBlockReasonCreate()
#Konamiman: shutdown.exe -a will abort a "scheduled" shutdown yes, but not a "normal" shutdown by someone calling ExitWindowsEx()
If anything else fails, remember that from command line it is shutdown.exe -a; maybe you could invoke this using the Process class.
EDIT. When mentioning the Process class I happily assumed that the question was about .NET programming, now I see that .NET is not mentioned neither in the question nor in the tags. Anyway I believe that there are ways to run executables from other programming environments as well.