I have universal project targeting Windows Store 8.1 and Windows Phone 8.1 platform.
The windows one works fine but I having trouble running the WP one on an emulator. I get the error message saying:
Microsoft Visual Studio Unable to activate Windows Store app
'numbers-here!App'. The Kiss.WindowsPhone.exe process started, but the
activation request failed with error 'Msg in polish that the app did
not start'.
If this was Windows I would check System Event Log and see the logs just before the error what DLL the system was trying to load and that helped a lot when I was debugging similar problem with Windows Store project, here I have no clue on how to check what exactly was being loaded.
The worst part is that I created package (appx) and checked the dll's being packed with exe, it seems that it includes dependencies that the app explicility uses yet something is still missing and this might be some 'hidden' dependency of one of the other dlls.
Any ideas how to debug such issues with emulator?
For me it was due to having WIC code in my App and/or calling CoCreateInstance in a windows phone environment ( on PC it works flawlessly though )
I ran into the same problem on Windows 10. Turns out, that there is no Kernel32.dll on Windows 10 phone!
Instead you need to link against OneCore.lib which provides the entire Win32 API subset that is supported in UWP. This "umbrella library" will load the correct dlls at runtime.
See also:
https://msdn.microsoft.com/en-us/library/windows/desktop/mt683763(v=vs.85).aspx
Related
I have an app which uses Boost libraries. On Desktop, the Windows UAP application works as expected, however, on phone (real phone or emulator), the app crash on start, and it is not possible to debug.
It seems the issue comes from the boost::thread library.
Here are simple steps to reproduce this issue:
Build boost thread and date_time (date_time seems required to link) from the command line with: b2 --with-thread --with-date_time toolset=msvc-14.0 variant=debug link=static architecture=x86 windows-api=store cxxflags="/AIC:/winrt". Note that "C:/winrt" is a junction to "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\store\references" where platform.winmd is (since it seems required to build)
Create a Blank C++ Windows 10 Universal app using Visual studio 2015.
Edit Mainpage.xaml.cpp and add a call to boost::thread like: boost::thread workerThread(workerFunc); where "workerFunc" is whatever function you want. Add the required include file ( #include <boost/thread/thread.hpp> ). In the link option, add boost thread lib.
Now run the app in a phone emulator.
Result: the app will crash at load time.
This happens on real phones with arm CPU too (with boost built with option architecture=arm). This issue can't be reproduced on desktop computers using the same app built for the emulator. Just run the app on your locale machine and it will work.
Am I missing something?
The issue seems to be that Windows UAP projects link by default with library which are not available in phones, like ole32.lib. So it compiles and work on desktop, but crash on phone, and there is no information about which dll creates the issue. Furthermore, the app validation software from microsoft doesn't provide any information about that.
I was also facing similar issue , app works fine in desktop but fails to load in windows phone emulator. I ran the certification toolkit and found out app is using restricted api (CryptGenRandom in advapi32.dll) which boost was using. removing that particular function call resolved issue.
Windows 7, VS2012-Update1, x64.
If i start e new MVC-project, and add the Azure project to it. I can't debug it locally in the azure emulator.
The error:
Operation taking longer than expected
A 64-bit debugging operation is
taking longer than expected. This may be caused by incompatibilities
with 3rd party networking softwar. See help for troubleshooting these issues.
When i Terminate that message (twice):
Windows Azure Tools for Microsoft Visual Studio
There was en error attaching the debugger t the role intances
'deployment18(18).mvctest.Azure.Website_IN_0' with prces Id:'8752'.
Unable to attach. The Microsoft Visual Studio remote debugging monitor
has been closed on the remote machine.
The first message, I already found that if you change your website target to x86 that this can solve the problem. (this solved a problem for debugging unit-tests)
But if I change it to x86, the nex message pops up:
Windows Azure Tools for Microsoft Visual Studio
Cannot start debugging. The role was built for a platform incompatible with the windows azure compute emulator. On this system the compute emulator supports anyCPU and x64.
If i start without debugging (not x86), the windows emulator starts, and the website opens.
Is there a solution to solve this that we can debug x64 websites on the azure emulator?
Thanks.
Problem solved:
The issue was, that oour normal account didnt had admin privileges, and that we had to use an other admin user his credentials to run it in admin mode.
If i logged on with that admin user and started everything, that user couldn't also load the azure emulator.
Every co-developer had the same issue.
But when the normal account had back the admin privileges, the emulator started normally.
So i assume that there was something missing for those admin account (what i don't know)
Ensure that the remote debugging service and the machine debug manager (for x64) are properly installed and running (services in Automatic, especially not disabled).
You can also try to download and reinstall the remote debugging tools following instructions here
Even if it is on the same machine, chances are that debugging for the emulator goes through the remote debugging path
Been googleing this for a while now and it looks like the problem is connected to network drivers installed on windows. Do you have a VPN installed? Uninstall it and try again.
Otherwise it could be some of the network card drivers. Same here, uninstall and try again.
Some people have solved this by upgrading visual studio.
Does a System.Runtime.InteropServices.COMException of 0x80040154 always mean that the class isn't registered? I'm getting a COMException which says "Retrieving the COM class factory for component with CLSID {29131539-2EED-1069-BF5D-00DD011186B7} failed due to the following error: 80040154." It's trying to load Interop.Domino.dll which is a reference I got from the COM tab of Add Reference called "Lotus Domino Objects" which points to domobj.tlb in the Notes program folder.
I wrote the code years ago - it's the only thing I've ever done with interop and it's fair to say that I never really got to grips with it.
I'm seeing this error again after moving the code to a 2008 R2 server (so it's x64). It was written on XP and run on 2003 (both x86). In order to diagnose the problem, I built a Win7 x86 (because there's no R2 x86) box and it worked. I also built a 2003 x64 box and it fails with the same error, so it looks like it's caused by moving to x64 architecture. Is there something I should do when doing interop to get x86 COM DLLs to work on x64 machines?
I had the same problem trying to build and run a .NET application on Windows 7 x64 that called interop.domino.dll, which is 32 bit only.
To resolve, I recompiled the .NET application to run specifically as x86 when run on x64 operating systems.
I was using Visual Studio 2010 Express Edition which is trickier to target specifically for x86 platforms than the paid for versions.
The solution was:
Click TOOLS > OPTIONS > PROJECTS AND SOLUTIONS
Check the box "Show advanced build configurations" and click OK
Click TOOLS > SETTINGS > check EXPERT SETTINGS to see the build configuration manager
Click BUILD > CONFIGURATION MANAGER select the platform dropdown to X86 and click CLOSE
Now rebuild the project
Pay attention to register of 32-bit components using the correct register (C:\Windows\SysWOW64\regsvr32.exe).
If you have already registered up with the 64-bit version, unregister each dll with the same version.
More help you find here Team is Going from XP32 to XP64 for .NET Development - Any Gotchas?
Good luck
There's an IBM technote that indicates that the Domino COM classes are not supported on a 64-bit OS. See https://www-304.ibm.com/support/docview.wss?uid=swg21454291 So it seems like even by compiling the code to run as x86 (as per mpownie's answer), you're still taking some chances.
I've developed an application in VS 2003 (C++). But while running in a fresh windows xp machine, getting error:
Microsoft Visual C++ Runtime Library
Runtime Error!
Program:
This application has requested the Runtime to terminate it in an unusual way....
What will be the reason for getting this error and how can I solve it? Please help.
This is a very generic error so it is not easy to solve from this information but I can give you a few things to try.
First check that the program runs fine on your developer machine - if not run under the debugger and trap the specific error.
If this problem only occurs on the clean machine it probably does not have the correct runtimes installed.
Your application will depend on a number of dlls that ship with visual studio, you will need to install these on the clean machine.
Your can run depends.exe from http://www.dependencywalker.com/ this will tell you what dlls cannot be found.
These dlls will be on your developer machine, you can either package the yourself in an installer or find the correct redistributable from microsoft.
Another thing to check - have you hardcoded any file locations? e.g. your application could try and open a file, resource, registry key - something that does not exist in your clean machine - if the code does not check for failure you would then probably crash at some point after the read failed to happen.
I have a method that loads a Crystal Reports file, sets the appropriate login information, and then generates a PDF.
ReportDocument rep = new ReportDocument();
rep.Load(...);
// Set table LogOnInfo
rep.ExportToStream(ExportFormatType.PortableDocFormat);
// Save the PDF to disk or return it as web request
This exact code works in both
A stand-alone WPF desktop application
An ASP.NET MVC website running through Cassini launched from VS
but does not work when the same website is deployed to IIS7. It gives a rather unhelpful message and stacktrace.
An error has occurred while attempting to load the Crystal Reports runtime.
Either the Crystal Reports registry
key permissions are insufficient or
the Crystal Reports runtime is not
installed correctly.
Please install the appropriate Crystal
Reports redistributable
(CRRedist*.msi) that contains the
version of the Crystal Reports runtime
(x86, x64, or Itanium) that is
required. Please go to
http://www.businessobjects.com/support
for more information.
Exception Details: CrystalDecisions.CrystalReports.Engine.LoadSaveReportException: An error has occurred while attempting to load the Crystal Reports runtime.
Note that I am using CR 2008 SP2 and the files haven't been named CRRedist... since 10.5 so someone has been forgetting to update the messages somewhere :) Here is a list of all the CR runtimes.
So why would running the same code referencing the same assemblies work in the two situations listed above but not in a deployed website?
I found this suggestion to give the IIS user write access to the temp folder, and it does appear that the Crystal runtime does some work there but I still get the same error even after giving IIS_IUSR or IIS AppPool\DefaultAppPool full access to %TEMP%.
I have also tried changing the app pool to use my account as the identity and still receive the same error message so I'm not convinced it's a permissions issue.
It turns out that for any newer versions of Crystal Reports after 10.5 (the one that is bundled with VS2008) there are no 64-bit runtimes.
The "simple" solution is to make the app pool 32-bit and then everything works ok.
There are more explanations found here (along with the expected angry responses)
You have to install CR version 13, download the msm and build an installer with VSS. Finalley execute the installer (you build) on your server.
Good luck!