I have an Excel XLL addin that crashes Excel on some computers.
In order to troubleshoot I added this call in DllMain:
SetUnhandledExceptionFilter(MyExceptionFilter);
and a filter itself:
LONG WINAPI MyExceptionFilter(struct _EXCEPTION_POINTERS *lpTopLevelExceptionFilter)
But filter never gets called on crash.
This is an old question, but just in case this can help somebody else: using SetUnhandledExceptionFilter() inside XLLs is not supported by design, quoting a Microsoft employee Jie Wang from http://www.office-forums.com/threads/setunhandledexceptionfilter-in-office-addin.2164345/
The behavior you observed is by design.
3rd-party addins/dlls cannot set the unhandled exception filter for Office
2007 apps (at least not in a supported way). MSO.DLL explicitly sets the
filter itself, then overrides the API to prevent 3rd-parties for changing
the filter after MSO has set it. It is common to all the Office apps (not
just Outlook).
So the only officially supported method of getting crash dumps from Excel is to use WER.
In practice, using MSVC-specific _set_se_translator() function does work however. But it must be called from all application threads, unlike the process-global SetUnhandledExceptionFilter().
Related
I am developing a small tool that can detecting which folders are being opened in windows explorer and bring it to front if a specific address has been opened.
I can use both C# and C++ and finally pick C# as it is easier than C++ to accomplish the same target. Then I googled the internet and knowing COM object SHDocVw.ShellWindows can help collect all windows being opened. Then I start looking for Microsoft document to see if any functions can help to achieve my other requirements. However, when I search shell related documents: https://learn.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ff521731(v=vs.85) I am warned that "We're no longer updating this content regularly. Check the Microsoft Product Lifecycle for information about how this product, service, technology, or API is supported." Moreover, some documents even say these techs will be deprecated in Win11 (See the following screenshot)
I am wondering what the status of these Shell related technical. If these are being deprecated. What's the alternative solution? I don't want my tool stop working when start using new Windows. Meanwhile, I am confusing in the study routine of learning Windows desktop technical. Looks like so many technical to achieve the same targets. Is there anyone can give me some road maps?
Last thing, it's really frustrating to search COM object documents at Microsoft sites. Is this tech going down?
Microsoft has been trying to kill win32/desktop applications since Windows 8. That parts of the documentation is labeled as "legacy" is not something I would worry too much about. Some of the shell functions have been marked as deprecated for 20 years but still work fine today and too many applications rely on them for Microsoft to successfully remove them.
The Internet Explorer warning is different and IE might actually go away but that does not affect IShellWindows which is also used by Explorer.exe and 3rd-party applications. Its implementation lives in a shell DLL and not in IE.
I am working on an application which collects a number of different pieces of system information. One thing I am collecting is a list of services and their descriptions as returned by calling QueryServiceConfig2.
When run on a system configured in a language other than English, the application returns the service names and descriptions in the systems default language. This makes sense but I would like to know if it is possible to force the API calls to return the descriptions in English, assuming the appropriate language pack is installed.
Ideally any solution would need to be compatible with XP and above. I have already tried using the SetThreadLocale function with both en-us (0x0409) and LOCALE_INVARIANT but it did not have any effect.
I did also see the function SetProcessPreferredUILanguages but my application is not a GUI app and also this function is only available on Windows 7 and above.
After multiple days of searching and tests I am at a loss. Is what I am trying to achieve possible?
We are having some strange issues on Windows Server 2012 (both normal and R2). Every once in a while (seemingly randomly) we start getting strange errors with all the programs on a server (API calls to Process32Next fail for instance). These occurrences seem to be a associated with one or more of our old ActiveX EXE (VB6) programs suddenly showing 'Embedding' in their description in the process viewer (task manager or Process Hacker). The problem goes away when everyone logs off. I cannot find anything much on Google about this. These programs have been around unchanged for over a decade and I cannot see how ANY program could affect every other program on a server but I am hoping that understanding why the Embedding description shows up might help lead to a solution.
Also, sometimes the name of the process is blank as well.
ActiveX EXE is another name for Automation Server. This is one of several technologies built on top of COM that fall into the OLE 1.0, OLE 2.0, and OLE custom control (a.k.a. ActiveX) categories. OLE stands for Object Linking and Embedding.
My guess is that wherever you are looking this term "Embedding" is being used to indicate an Automation Server. So it probably has no direct bearing on your issues.
I suspect this is a case of "looking where the light is good."
You may be running into some issues related to Session 0 Isolation, User Interface Privilege Isolation, or both. Or more likely you might have DCOM/Automation activation settings incorrect for one or more of these programs.
You might start by looking at the definitions for these servers in DCOMCNFG.EXE. People often rely on defaults and that may not be what you should have. Some of these might be defined in COM+ which means additional rules. Some of these interact with user rights and group membership.
But we have far too little specific information to really be of much help here.
This is somewhat complex issue with several questions. Feel free to answer only the questions to which you have an answer.
I have a task to create minidumps in case of Windows exceptions for several of our components, and to support XP SP3 as minimal OS. Components include:
Standalone C++ apps
CSP and PKCS11 libraries (DLL's) to be used in known browsers
one UI and one non-UI service
Static libraries, which are used in all previous three points
The requirement is to have something like WER (from XP onward), but to send reports to dedicated vendor server instead of to Microsoft's current Winqual equivalent. It would be really nice the reporting functionality could be wrapped in one static library.
There are issues, though. DLL's are special beasts. How to generate a report only if fault happens in DLL code? Services may also require some special handling, of which I'm currently unaware.
First of all, is there a known open-source library that could help me with this task? If not, I'd have to roll my own.
My first thought is to have a sleeping watchdog thread in each of my modules. This thread just waits on an event, which will be set from unhandled exception filter. The thread would generate the report using MiniDumpWriteDump, send it over the internet and then finish, and in the mentioned filter we would wait for the thread to end, and then terminate the process. Any thoughts on this solution? For instance can Windows service under local system account access the internet at all?
You don't need to create a thread that "waits for an exception".Just register your own Exception handler using UnhandledExceptionFilter. Look at this URL, it is well explain how to take MiniDumpWriteDump when an exception occurs.
Windows services that run under local System credentials don't have network access.
Where can I find the orginal vb6 ( or windows ) icon? (.ico files)
I need, error, warning, question, and information icons which come up on the messagebox.
Thanks a lot.
As the icons can differ for each OS version, you can get the icons from Windows using LoadIcon() passing one of the standard icon IDs.
See http://msdn.microsoft.com/en-us/library/ms648072.aspx for details.
If you want them as .ico files, you can extract them (on your development machine) from user32.dll using a resource editor.
(Updated with corrected info from Cody Gray)
The standard Windows message box icons have changed many times across the various versions of Windows. They're included with a couple of the system DLL files, but you shouldn't try and extract them dynamically yourself. As I mentioned in a comment to another answer, the ID numbers are undocumented for a reason: namely because it's possible for them to change in future versions of Windows or even in future Windows updates. There's absolutely no reason to go through the effort trying to extract them, either. Windows will already retrieve them for you, if you ask nicely.
The nice way of asking is to use the LoadIcon function, and specify the IDI identifier of the icon you want. Windows will return an HICON value, or a handle to an icon resource.
Since you mention that you're using VB.NET, you can also use the SystemIcons class, which has static properties to return any of the common icons. This is a .NET wrapper that saves you from having to P/Invoke the LoadIcon function from the Windows API yourself.
Better yet, if you just want to display a message box containing one of the icons, all you have to do is call the MessageBox API function. Tell Windows the MB_ICON value that you want, and you're off. As before, this has already been wrapped for you by the .NET Framework in the identically-named MessageBox class.
The benefit of both of these functions is that they'll always return the correct icons regardless of the current version of Windows. A comment made attempting to clarify the question seems to suggest that you want to use the old icons on a current version of Windows. But of course, you do not want to do this. The icons have been updated throughout the Windows shell for a good reason, and your application should take advantage of them. The new icons are more clear and fit in better with the overall system theme. Additionally, if your app still uses the old icons, it will be confusing to users and look very out of place. It's always best to follow standard platform conventions, rather than trying to do "something else", even if you think your "something else" is "better" for whatever reason than the platform default. Your users will not agree, and your application will reflect your shoddy craftsmanship.
Since people who ask this type of question inevitably disagree with me and insist that they must do it anyway, and that it is a "requirement" (whatever that means), I'll point out that the old icons are not available in the newer versions of Windows. The icons have been completely replaced throughout the system for a reason. It's also strictly forbidden by the licensing agreements to extract icons from system DLL files and redistribute them with your application. Don't do this.
Also, before deciding on which icon you should display in your message box, be sure to consult Microsoft's Windows User Experience Interaction Guidelines, which provide some very handy rules on selecting the proper icon to convey the right message and fit with the Windows tone. I provide more information on that in my answer here; very much recommended reading for any Windows application developer.
Edit: It's like pulling teeth to get any more details on this question. I'm not sure why you're so secretive about what you're trying to accomplish, but note that in the future, you'll have a lot better luck including these things in your question to start with, rather than hoping people will pull it out of you. Most people aren't nearly as persistent as I am.
Anyway, you finally mention that you're doing some type of interop between VB 6 code and .NET code. That should not be relevant in the case of the message box icons used. The VB 6 MsgBox function is 100% equivalent to the Win32 API MessageBox function and the .NET MessageBox class that I discussed earlier. All of them are going to use the current system icons, and it shouldn't require any extra work to make them look the same. Ensure that you've passed the same icon specifier to all of the functions. Here's a table for convenience:
VB 6 "MsgBox" Icon Constant | VB.NET "MessageBox" Icon Identifier
---------------------------------------------------------------------------------
vbCritical | MessageBoxIcon.Error
vbQuestion | MessageBoxIcon.Question (DEPRECATED -- do not use)
vbExclamation | MessageBoxIcon.Warning
vbInformation | MessageBoxIcon.Information
Note that the "Question" style icon has since been deprecated and you should not use this value. If you're still using it in the VB 6 code, you should change that code to use a different icon (or no icon at all). The above-linked Windows User Experience Interaction Guidelines provide more details on why this icon has been deprecated and how to choose a suitable replacement.