I have created a nearly blank Windows IOT Core background task and if I include a method that use the "double" data type it will throw an SEHException if I step-over it after hitting a breakpoint. I have seen these weird things before when the versions of IOT Core installed on the PC vs. Raspberry PI don't match, but as far as I can tell I have things matching. Any ideas?
I have tried:
Changing the target min/max version in the VS Project.
Updated to the latest Universal Windows nuget packages
Ensured that the OS version on the PI (10.0.17763.107) matches the UAP version show in visual studio (though is says 10.0.17763.0), I can't find any way to change that
Even downloaded newest version of VS 2019, same thing
Simple code (do not step-into the method, if you do that it works):
public sealed class StartupTask : IBackgroundTask
{
public void Run(IBackgroundTaskInstance taskInstance)
{
double x = DoNothing();
Debug.WriteLine(x);
}
public double DoNothing()
{
return 300.7D;
}
}
Exception I get when step-over:
https://imgur.com/osiJngg
I am trying to build The Mypintool sample that comes with pin distribution for x64 architecture.
I am using pin3.0 (build 76991) and Visual Studio 2012. The build is successful if I have not included windows.h.
But if I include window.h (in a separate namespace) like this:-
namespace WD {
#include "Windows.h"
}
Then the build gives the error :-
C:\Program Files (x86)\Windows Kits\8.0\Include\um\winnt.h(3486): error C2888: '_CONTEXT::<unnamed-tag>' : symbol cannot be defined within namespace 'WD'
C:\Program Files (x86)\Windows Kits\8.0\Include\um\winnt.h(3488): error C2888: '_CONTEXT::<unnamed-tag>::<unnamed-tag>' : symbol cannot be defined within namespace 'WD'
Also, I am able to build the tool for win32 with windows.h included without any issue. Also, I have compared the build settings for win32 and x64 and I could not find any discrepancy.
Any help is appreciated.
It is unclear to me if you have a windows application that makes use of "Pin" or a "Pin" application that needs to call some Windows APIs - or a hybrid where massive use of both APIs exists in a single program.
Nonetheless, the Windows SDK is quite large, and is designed (mostly) to work with C, or with a subset of C++ compatible with C so it cannot be expected to work if wrapped in a namespace.
So, your only effective way to deal with a conflict in headers, is to avoid it by never including the "pin" or "windows" headers in the same cpp file. You need to partition the parts of your program that call windows, and that call "pin" into separate cpp files.
Create a bridging header file that defines classes and functions that use only C++ declarations. As it makes no use of either pin, or windows, this file can be #included by both sides of your project. Of course, depending on what your application is attempting to achieve this may be difficult so you might have to engage in some heavy duty type erasure.
Something like this:
// pin.cpp
#include <intel/pin.h>
#include "bridge.h"
void method(){
Window* wnd = Window::Create();
wnd.Show();
}
.
// bridge.h
class Window {
public:
static Window* Create();
virtual void Show()=0;
};
.
// WindowsImpl.cpp
#include <windows.h>
#include "bridge.h"
class WindowImpl : public Window {
HWND hwnd;
public:
bool Create(){
hwnd = CreateWindowEx(...);
return hwnd != NULL;
}
void Show() override {
ShowWindow(hwnd,...);
}
};
Window* Window::Create(){
WindowImpl* newWnd = new WindowImpl();
newWnd->Create();
return newWnd;
}
I have problem when I am building project in Visual Studio 2010 for 64bit. I couldn't able to build for 64bit with boost library, I am getting below error. I can build for 32bit but not for 64bit.
\boost_1_49_0\boost\thread\win32\basic_timed_mutex.hpp(159): fatal error C1001: An internal error has occurred in the compiler
(compiler file 'f:\dd\vctools\compiler\utc\src\p2\wvm\mdmiscw.c', line 2704)
5 To work around this problem, try simplifying or changing the program near the locations listed above.
5> Please choose the Technical Support command on the Visual C++
5> Help menu, or open the Technical Support help file for more information
5> The command exited with code 2.
It is pointing error to the below code and ofcourse I can't change the boost library. I am confused with this error
void unlock()
{
long const offset=lock_flag_value;
long const old_count=BOOST_INTERLOCKED_EXCHANGE_ADD(&active_count,lock_flag_value);
if(!(old_count&event_set_flag_value) && (old_count>offset))
{
if(!win32::interlocked_bit_test_and_set(&active_count,event_set_flag_bit))
{
win32::SetEvent(get_event());
}
}
}
Can you please help me,
Thank you
Edited :
I am not sure where the error but I think its in the boost libraries, there is a cpp file like
Class a::a(, point, )
{
}
and the "point" is a namespace which is defined in a header file which is using boost libraries and it has following code
#include <boost/thread.hpp>
#include <boost/thread/recursive_mutex.hpp>
namespace point
{
// some work1
void fun()
{
boost::unique_lock< boost::recursive_mutex > lck(*m_RedrawMutex);
// some work2
}
// some work3
}
Answer :
It finally worked !! After two days of search, I found another way.I just changed the order of include path in the project header where it was using boost basic_timed_mutex.hpp. I placed boost include path at the top and it worked. It's strange!!!
I've had this same issue myself - and it seems to be related to certain code-blocks in boost itself. It appears to be caused by a bug in the MSVC compiler toolchain.
Disabling optimisation appears to solve the issue for many users As per this MSDN article - Source from MSDN suggesting this fix Souce on stack-overflow
I wish I could present a logical cause, or bug report on the issue, but for myself the problem was solved by upgrading to Boost 1.60.
That said, other uses have reported that trailing-slashes are the cause!
update:
After some browsing it appears this issue can be caused by everything from infinite-loops, though to templates types holding function pointers. and doesn't always list the actual-source of the error correctly (eg: it's not where the error message says it is). That said, disabling optimisation appears to solve the issue near universally - at the cost that your software may run slower.
My product has a helper executable to uninstall all related sub-products. I uninstall based on upgrade codes of all sub-products.
First, I fetch the product code from upgrade code using MsiEnumRelatedProducts function. Then I try to uninstall the product using MsiConfigureProductEx function.
The problem is MsiConfigureProductEx is returning error.
Invoked Function: MsiConfigureProductsEx
Return Code: 1605 (0x00000645)
Description: This action is only valid for products that are currently installed.
Why is MsiEnumRelatedProducts returning a invalid product code ? I searched through the windows registry to see if such product code exists. There isn't any. How to debug the issue ?
Edit: Added minimum code that reproduces issue.
// UpgradeCodes is an array having upgrade codes of all modules.
TCHAR lpProductCode[GUID_STR_LENGTH];
const TCHAR tszNoReboot[] = _T("REMOVE=ALL REBOOT=ReallySuppress DISABLE_REBOOT_PROMPT=1");
for (size_t i = 0; i < sizeof(UpgradeCodes) / sizeof(UpgradeCodes[0]); i++)
{
tstring tstrUpgradeCode = UpgradeCodes[i];
DWORD dwIndex = 0;
size_t status;
// for each of the upgrade code, get all the products
do
{
status = MsiEnumRelatedProducts(UpgradeCodes[i],
0,
dwIndex,
lpProductCode);
if (ERROR_SUCCESS == status)
{
UINT uiReturn = MsiConfigureProductEx(lpProductCode,
INSTALLLEVEL_DEFAULT,
INSTALLSTATE_DEFAULT,
tszNoReboot);
if (ERROR_SUCCESS_REBOOT_REQUIRED == uiReturn)
{
// prompt for reboot at the end of all modules uninstallation.
}
if (ERROR_SUCCESS != uiReturn)
{
// log message with return code.
// Error Code: 1605 is coming from here.
}
}
}while (ERROR_NO_MORE_ITEMS != status);
}
Some years have passed and I want to add two scipts that can be used
to export MSI package information:
How can I find the product GUID of an installed MSI setup? - in section 2.
Do visit the link above, but here are direct links to the scripts:
1) the html export version and 2) the simpler text output.
Disclaimer: The below information is very "under the hood". Please use API calls whenever you can to access the MSI database. Also remember to run all your MSI testing on virtual machines so you can easily revert to a "clean state". During MSI development strange things can happen.
It is possible that a previous uninstall of that product of yours left something registered upon uninstall, and this is causing all the problems. I would try to check with scripts what is registered on the system.
Found good discussions of retrieving product info with VBScript here, a couple of really good scripts - recommended. Go to the sites to find the scripts, they format pretty poorly here and clog the answer.
http://forum.installsite.net/index.php?act=ST&f=26&t=14035
http://www.dwarfsoft.com/blog/2010/06/22/msi-package-code-fun/
The Windows Installer database is mostly located here:
HKEY_CLASSES_ROOT\Installer\
The upgrade code section: HKEY_CLASSES_ROOT\Installer\UpgradeCodes
You must never touch anything in the Windows Installer Database Registry directly. It's extremely interconnected and easy to corrupt. Only go through the APIs. Note that the GUIDs in the registry are packed, so you won't find the GUIDs from the package in the registry.
Packed GUID: 03B1692A57845354EA63AD602436AB05
Regular GUID: {A2961B30-4875-4535-AE36-DA064263BA50}
Using the VBScripts above and the registry data directly for inspection you should be able to determine what is happening in the Windows Installer database.
I would never work straight in C++ to test this out. Instead I would eliminate some complexity by trying PowerShell or VBScript to determine what is wrong with the uninstall routine. You can find information on how to use these scripting tools here in this thread. And here is another thread.
It is not quite clear if some of the uninstalls work, and there is
one that fails or if the uninstall operation fails altogether? That's
the first question.
Have you tried manually uninstalling all products from add/remove to ensure they all uninstall correctly manually? One of the products could trigger an error return code during uninstall that is caught programatically, but is ignored during manual install. Often these can be from Custom Actions placed after InstallFinalize. In this case some setup redesign is called for. In the simplest case it would involve disabling error checking for the custom action, but that fix is not good enough in my opinion.
It is possible that the product is
installed, but per-user. In other words it might be installed only
for a single user on the machine, and not for the machine (this is controlled by the ALLUSERS property). I am not sure how this function works if this is the case - it may even report the product as advertised (available for on demand install via a shortcut, but not actually installed). Again, I have not tried this, and uninstall may still work. Just off the top of my head to try and give you some pointers.
Have you performed any major upgrades of existing MSI files as part of the install of your product?
One further question: are you running on Windows 8? And are these MSI files generated with WIX or some other tool? There have been some intermittent reports on problems that appear at least remotely similar.
If you have a package installer (like Microsoft SQL Server), it can install a host of other items during its installation phase.
Later, when you go to uninstall the big package installer, all of the items that installer added to the system should theoretically be removed.
So, try just uninstalling your application, stop, then look to see if the other smaller applications are still on the system.
If they are, then you will need to uninstall these individual applications first when your custom uninstall script starts.
I assume you already have a System.Configuration.Install.Installer class. Follow a set of steps when installing your application (1, 2, 3, etc.), then perform these steps in reverse order when uninstalling your application (3, 2, 1).
Trying a new approach for you. I have located two products that seem to have at least two productcodes registered for their upgrade codes. They are: MSVC redistributable 2008 and MSXML 4.0 SP2. I have written a small C++ test that seems to work ok.
Essentially I think you need to check for ERROR_NO_MORE_ITEMS before the next iteration of the loop so you don't try to uninstall products that are no longer installed.
Here is some VS2013 code that should compile out of the box on a fresh install, empty project.
UPDATE: updated code to use VS2017 and a minimal console application.
Create a new console project: File => New => Project... => Visual C++, Windows Desktop, Windows Console Application
Paste the below code into the main CPP file (replacing whatever is there)
Set a breakpoint and build & run (F5)
F10 to step through
If "Microsoft Visual C++ 2008 Redistributable" isn't installed, no related product codes will be found.
#pragma once
#include "stdafx.h"
// The below should really be in stdafx.h (precompiled header)
#define WIN32_LEAN_AND_MEAN // Exclude stuff from Windows.h
#define STRICT
#include <windows.h>
#include <msi.h>
#pragma comment(lib, "msi.lib") // To make code link
int main()
{
UINT i = 0;
UINT status = ERROR_SUCCESS;
TCHAR productcode[39] = {};
const TCHAR upgradecode[39] = L"{AA783A14-A7A3-3D33-95F0-9A351D530011}"; //Microsoft Visual C++ 2008 Redistributable
//const TCHAR upgradecode[39] = L"{7CE723E3-E56B-432C-9F24-78C0606045A5}"; // MSXML 4.0 SP2 (KB973688)
do
{
// look up (related) product code(s) for specified upgrade code
status = MsiEnumRelatedProducts(upgradecode, 0, i, productcode);
if (status == ERROR_NO_MORE_ITEMS) // Test here. 259, ERROR_NO_MORE_ITEMS
{
// No more productcodes for specified upgrade code
MessageBox(NULL, L"No more productcodes", L"Done", MB_OK);
break; // exit do-while loop
}
i++; // Next product code
MessageBox(NULL, productcode, L"Product Code:", MB_OK);
} while (status != ERROR_NO_MORE_ITEMS);
return 0;
}
There could be erronously registered products on your system due to failed major upgrades or similar advanced error scenarios, so I am not sure if this solves your problem.
Keep in mind that the Windows Installer Database at HKEY_CLASSES_ROOT\Installer\UpgradeCodes contains packed GUIDs. You can try the VBScript code found in the following link to convert back and forth between packed and regular GUID formats: http://www.symantec.com/connect/blogs/guid-converter
More info on guid formats here if it is interesting: http://www.symantec.com/connect/articles/working-darwin-descriptors
// TEST DATA 2014 (guids in different formats):
// UpgradeCode
// 41A387AA3A7A33D3590FA953D1350011 => {AA783A14-A7A3-3D33-95F0-9A351D530011}
//
// ProductCode
//
// Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.4148
// CFD2C1F142D260E3CB8B271543DA9F98 => {1F1C2DFC-2D24-3E06-BCB8-725134ADF989}
//
// Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.17
// D20352A90C039D93DBF6126ECE614057 => {9A25302D-30C0-39D9-BD6F-21E6EC160475}
// UpgradeCode
// 3E327EC7B65EC234F942870C0606545A => {7CE723E3-E56B-432C-9F24-78C0606045A5}
//
// ProductCode
//
// MSXML 4.0 SP2 (KB973688)
// 6E8A266FCD4F2A1409E1C8110F44DBCE => {F662A8E6-F4DC-41A2-901E-8C11F044BDEC}
// MSXML 4.0 SP2 (KB954430)
// DDA39468D428E8B4DB27C8D5DC5CA217 => {86493ADD-824D-4B8E-BD72-8C5DCDC52A71}
Iam using a 3rd party c++ dll in my asp.net web application.
dll - 64-bit
asp.net Platform - Any Cpu
asp.net Framework - 4.0 (vs 2010)
System Os - Win 7 Professional (64-bit)
I have placed the dll in the Applications folder and called the dll with its full path as:
[DllImport(#"D:\Application\Sampledll.dll",
EntryPoint = "SampleFunc",
CharSet = CharSet.Ansi,
CallingConvention = CallingConvention.StdCall)]
public static extern int SampleFunc(char[] ch1, char[] ch2);
But I got the below result:
An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
When searched with the Error code: 0x8007000B - It meant 'Using 32-bit dll on 64-bit system'
But the dll is 64-bit dll....
Any how I tried the solution of this error by changing the Target Platform of VS to 'x86' & 'x64' and setting 'Enable 32-Bit Application' property of IIS to 'True'
But got the same error.........
Can any one help to get around this problem....
Error code 0x8007000B is the COM error code that represents the Win32 error ERROR_BAD_FORMAT. Normally when a 32 bit process tries to load a 64 bit DLL, or vice versa, the error code is ERROR_BAD_EXE_FORMAT which would appear as 0x800700C1 when wrapped in a COM error code.
Therefore, I think that the problem is not a 32/64 bit mismatch. The most likely explanation is that the DLL, or one of its dependencies, is corrupt.
In order to debug this I would remove the complexity of IIS. You've got added layers of p/invoke and IIS to deal with. First of all make sure that you can load this DLL from another native program. Create a 64 bit C++ console app in VS that does this:
#include <windows.h>
#include <iostream>
int main()
{
if (!LoadLibraryA("D:\\Application\\Sampledll.dll"))
{
std::cout << GetLastError() << std::endl;
}
}
See what happens when you run that. If you get an error code, what value is it? Is it ERROR_BAD_FORMAT? At this point I'd use Dependency Walker in Profile mode to try to work out which DLL is the trouble maker.