I'm working on Visual Studio 2012 running on Windows 8 (32 bit), developing Windows Store app with C++
The app runs smooth on "local machine". But when I try to run it on the simulator, Build and Deploy succeeds but the simulator keeps loading forever! (dots coming from left and leaving at right)
When I close the simulator from the taskbar, VS gives me the following error: Unable to start the simulator. Cannot process request because the process (####) has exited.
I've been searching everywhere for a solution for a week now. The possible solutions I found were:
1. Changing the fDenyChildConnections registry.
2. Checking the "Automatically use my Windows logon name and password (and domain if any)" checkbox from the security tab of the network.
3. Updating graphics driver.
4. Disconnecting all networks.
5. Restarting VS/making new project.
6. Launching simulator from C:\Program Files\Common Files\microsoft shared\Windows Simulator\11.0\Microsoft.Windows.Simulator.exe
7. Updating VS.
The problem is still there. Does anybody have a solution?
I performed a clean install of Windows 8.1 x64 and the simulator is running smoothly. I guess running 32 bit windows on a 64 bit architecture was the cause of this issue.
Try to see if "Remote Desktop Services" is enabled, if no enable it as manual and start it.
I had the same issue and the reason was lack of Hyper-V. I installed Hyper-V and the simulator worked.
Related
I have a Universal Windows Platform app that was working fine. My development machine is running Windows 10, and after the Windows 10 November Update (1511, build 10586), the development version built by Visual Studio has stopped working. I was actually running this day-to-day as a standalone app, and I noticed this problem when after the update the app started immediately closing after the splash screen.
I uninstalled the development version of my app and installed the store version, and that works fine, even though no code has changed between the two versions. I updated Visual Studio to Update 1, and it still doesn't work. I've fully uninstalled and reinstalled Visual Studio but that didn't help either. I've also tried changing the Project Properties to target platform version 10.0.10586.0 and rebuilding, but that also doesn't seem to help.
This occurs on both Release and Debug builds, and on both x86 and x64.
On launch, it gets as far as the splash screen before informing me that I've triggered a breakpoint. The breakpoint was not set by me, but rather is in KernelBase.dll, and no source is available.
If I hit Continue, then I get an Unhandled exception at 0x00007FFC4C431F08 (KernelBase.dll). The body of the error is:
0x00000004: The system cannot open the file (parameters: 0xFFFFFFFF80004005, 0x0000000000000005).
Hitting Continue again will get me into my code, which dies with:
Microsoft C++ exception: Platform::COMException ^ at memory location 0x000000C1517FAF50. HRESULT:0x802B000A The text associated with this error code could not be found.
Any ideas on what happened and how to correct?
I see the following error whenever I try to debug "Cross Platform" under "C++" category: "Unable to start debugging. Unexpected GDB output from command "-target-select remote :5039". Remote connection closed"
I've installed all of the contents when I downloaded Visual Studio 2015 community and I ran it on Windows 10 Pro which supports Hyper-V.
I've been searching a solution for this and I've found an assumption:
"What is your debug target, the VS Android Emulator? When we saw this before it turned out to be a bad emulator image. Do you have this problem with all targets (e.g. if you try a physical device) or just one?"
In my case, I just tried this via Emulator(VS Emulator 5" Lolipop (5.0) XXHDP Phone (0x86 -...)
So I've sent an Email to VS 2015.
And the answer was like this:
"Sorry for the delay in responding we were looking at an emulator image of another user that ran into this problem so I was waiting until we had the results of that investigation to report back. We actually were not able to find anything wrong the emulator itself, our current hypothesis is that it is a network or adb problem interfering with GDB’s ability to connect to GDB server on the remote machine. Do you see this error every time you try to debug, or if you reboot the emulator will it work sometimes right after the reboot? Next time you see the error, can you open the emulator’s console mode by going go the Hyper-V manager and double clicking the emulator. Then find the location your app installed to and run “gdbserver --version" from the app path and let me know what it says? This will validate if the correct version of gdbserver is on the device."
So we are trying to solve this problem but I'm also asking here just in case.
Is there anyone who has magical solution for this problem?
I'll put a comment on this if I figure out how to solve this.
Thanks in advance.
** Following answer is from the manager of Visual Studio 2015:
You are only the second person who has run into this issue, and the first person that ran into it provided their everything works correctly when we run their .vhd on our machines so it appears to be some strange problem where gdbserver (which comes from the Android NDK provided by Google) crashes only when running on certain machines. Unfortunately the .vhd you provided does not appear to be the correct one it won’t boot for me. You can see the .vhd file being used by the emulator if you look under the settings of the emulator in your Hyper-V manager. .However given we got the other person’s .vhd you can hold off providing any additional information at this point. I’m waiting to hear back from the emulator team on if they have any ideas since this appears to be an issue only on specific machines since.
If you don’t mind my asking, if you don’t have a background in computers what inspired you to try C++ on Android? That scenario will be significantly more complicated than doing Java on Android.
It's been almost two months since I got this answer but I haven't got any additional response from them yet. So, I ended up quitting developing an application by using VS2015.
If you run into this problem, there are only two ways to go. Change your computer or stop developing application via VS2015.
If the project name contains spaces, the whole remote debugging fails. Visual Studio also creates weird paths. When checking out the "Blink1 for Raspberry Pi" template, I named the Project "Blink1 for Pi", which resulted in a path like this:
~/projects/Blink1?/for/pi/PI/for/pi....
And all the debugging failed. When I recreated this keeping the project name "Blink1", everything worked fine. It's a pity, that spaces aren't handled here...
I am currently trying to build a simple Win 7 x64 USB driver using this guide: https://msdn.microsoft.com/en-us/library/windows/hardware/hh706187(v=vs.85).aspx
Host is using VS2013 & WDK 8.1
Because I don't have a null-modem cable (or any other means of setting up a debugger connection between host and target), I just filled my settings with the default ones found here, expecting some sort of error to return, but the configuration process went through without a hitch, displaying
WDK Remote User Account successfully created
Installing .NET Framework 9possible reboot)
Installing VC Redist (x64)
Installing test automation (x86)
Installing test automation (x64)
Installing debuggers (x86)
Installing debuggers (x64)
Installing driver test framewok
Registering logging components
Configure debugger settings (x64) (possible reboot)
Configure computer settings (x64) (possible reboot)
Creating system restore point
Complete
So I assumed that what I assumed about serial/com ports to be wrong and continued to attach the WKM Debugger to 'Kernel' of my target computer, which was listed under the "Available Processes" datagrid. When I click the 'Attach' button, however, I get an error that says:
Windows Debugging Extension for Visual Studio
Could not start debug session, error 80070002: The system cannot find the file specified
I've tried Building/Rebuilding the project many times, and Provisioning the target computer also multiple times to the same results. I saw that question number 25776839 also had the same issue as me, but he mentioned something about changing VS's default from Kernel Debugger to Remote Debugger, which I'm not sure how that can be accomplished, but also caused other problems. I've also tried to "attach process" using the same setting via WinDBG but did not produce anything useful.
Also, I switched from MSVS2015 and WDK10 to MSVS2013 and WDK8.1 because their tutorial files led me to missing header files (warning.h many others), and package files.
Can anyone show me what I did wrong or what I need to do to fix the 80070002 error? Yes, I am new to driver dev.
I am new to Windows CE programming.
I have Visual Studio 2008 and Visual Studio 2005. I have found the following SDK for Windows Mobile
http://www.microsoft.com/downloads/details.aspx?familyid=06111A3A-A651-4745-88EF-3D48091A390B&displaylang=en
Please help me in deciding if this is the correct one, or please feel free to redirect me the correct one
Thanks in advance
Sujay
If you are targetting a Windows CE device (and not Windows Mobile), then each device has it's own specific SDK. If you are not using a device specific functionality, you create a C# for Windows CE 5.0 application and it will work on every Windows CE device that has the .Net component included in the image.
Don't mix Windows CE and Windows Mobile. Windows Mobile 5-6.5 is based on Windows CE 5.0, but has a standard SDK (different SDK's for different versions of the Windows Mobile at use). Windows CE, as I mentioned, is used in specific solutions and you should get the SDK form the OEM.
If you need a Windows CE Emulator get it here
http://www.microsoft.com/downloads/thankyou.aspx?familyId=a120e012-ca31-4be9-a3bf-b9bf4f64ce72&displayLang=en
and to setup the Emulator look at this guide http://www.hpc.net/chat.asp?ObjectID=97662
Edit: The hpc.net link is now dead so here is what was found on the page using the wayback machine. https://web.archive.org/web/20070428121320/http://www.hpc.net/chat.asp?ObjectID=97662
Connecting the CE 5.0 Emulator to VS2005
This uses the network method and saves the emulator state. It does not use activesync, communications ports or a null modem cable.
Start the emulator using a shortcut command that is something like this:
"C:\Program Files\Windows CE 5.0 Emulator\Emulator_500.exe" nk.cem
/video 640x480x16
/Ethernet virtualswitch
/sharedfolder "C:\CE5SharedFolder"
The shared folder appears on the emulator as \My Device\Storage Card. Using the shared folder, copy the following files to the \My Device\Windows\ folder on the emulator. These files are located on the host at \Program Files\Common Files\Microsoft Shared\CoreCon\1.0\Target\wce400\x86, or similar
Clientshutdown.exe
ConmanClient2.exe
CMaccept.exe
eDbgTL.dll
TcpConnectionA.dll
Select Emulator -> Start Menu -> run -> \Windows\conmanclient2.exe.
Get the IP address of the emulator by double-clicking on the T networking symbol bottom left. If it has no ip address try installing Microsoft Loopback Adapter on the host, check for Virtual Machine Network Services, or other host networking hacks. (This is the difficult bit).
To check that the emulator is responding, on the host type Ping at a DOS prompt.
To get "Save State" working on the emulator, shut down the emulator using the "Save State" option. Then navigate to Host -> My Documents -> My Virtual Machines
The saved state is in the folder that is named with a curly brackets string similar to {06A8A448-EB8B-4E0B-8A88-451412A10C66} say, and known as a GUID. Attempt to rename this folder so that you can highlight and copy the GUID string itself (not the folder).
Then add an option, which is similar to /vmid {06A8A448-EB8B-4E0B-8A88-451412A10C66}, to the emulator shortcut command above.
The shortcut should now start the emulator from its saved state. It is a good idea to back up the saved state folder.
On the host select Visual Studio 2005 -> Tools -> Options -> Device Tools -> Devices
Then select Windows CE 5.0 Device -> Properties -> Configure
In the "Configure TCP/IP Transport" dialog box, select "Use specific IP address", and then type the emulator IP address you found above.
Close the dialog boxes.
Select Emulator -> Start -> run -> \Windows\cMaccept.exe and connect to the emulator from VS2005 within three minutes.
Run your application from Start Debugging in VS2005 and VS2005 should deploy the two cab files nectcfv2.wce5.x86.cab and system_SR_enu.cab first (this may take some time), and then your application.
Close your application in the emulator (I've had trouble using the Stop button on the host).
Shut down the emulator using the "Save State" option.
You may need to re-run cMaccept each time you restart the emulator or VS2005, but the cab files should not need to deploy again, and the emulator ip address should remain the same.
To avoid cMaccept navigate host -> programs -> Microsoft Visual Studio 2005 -> Visual Studio Remote Tools -> Remote Registry Editor
In the "Select a Windows Device" dialog box that appears highlight the "Windows CE 5.0 Device" option
In the emulator run cMaccept and then immediately click OK in the Remote Registry Editor
Highlight Windows CE 5.0 -> HKLM -> System
Right click in the right hand pane and select New DWORD value.
In the name field type (exactly and without the quotes) "CoreConOverrideSecurity" and set its value to 1
Close the editor. Shut down the emulator with Save State.
First off, Sujay, I'll assume you didn't mean Windows CE explicitly. I'll assume you meant programming for handheld devices running a Microsoft operating system. CE hasn't been used for five or six years. The devices are all running Windows Mobile. 6.5 is the most popular now.
You do not need an SDK to program for Windows Mobile in Visual Studio. It is already baked in. If you want to get the latest tools to develop on Windows Mobile 6, then yes, the location you specified is perfect.
Here's another great place to get high-level info: Windows Mobile Development Center
I think you can use C# and create smartdevice project,
and use c# for making apps,use unmanaged code by improting DLL's..
for more sample just see "Program Files\Windows Mobile 6 SDK\Samples\PocketPC\CPP"
here u get some samples.
I've written a C++ console application in Visual Studio 2019 and am trying to deploy it to another windows laptop. Both laptops are up-to-date with 64 bit Windows 10, and my target laptop has installed/up-to-date .NET Framework, vc_redist.x64.exe, and DirectX.
In terms of deployment method, I followed this Microsoft walkthrough word for word, with the added step of ensuring that my newly created "setup" project was also targeting x64 platform, since some of the external libraries in my code required x64. The resulting "setup" .exe/.msi pair work as planned on the source laptop - installs and runs with no frills required.
Installation goes fine on the target laptop, but launching the program gives the error mentioned in the title of this post. After a few hours of trying to figure it out, I think I have an idea where the problem is coming from, but first, I'll share what I've tried, which is basically every recommendation found by googling this error code:
clean boot
SFC scan
chkdsk c: /f /r
repairing/fresh installing all of the frameworks mentioned in the first paragraph
running both the application installer and the installed application as administrator
restarting laptop and reinstalling application after all of those changes
What I think is the root of the problem:
In the setup/deployment project in VS, three of the "detected dependencies" (MSVCP140D.dll, ucrtbased.dll, VCRUNTIME140D.dll) have filepaths through …\System32\ rather than the identical dependencies that could be found in …\SysWOW64. The other two detected dependencies are external 64-bit DLLs (which is why I specified my entire project to x64). When I run my application through Dependency Walker, it agrees that the three formerly mentioned dependencies are "wrong CPU type", while the two latter ones are fine. This scenario does not, however, explain to me why install/run (outside of VS) works fine on the source laptop (shouldn't it not work if VS is packaging a mix of 32 and 64 bit dependencies?). In fact, running the application through Dependency Walker on the source laptop reveals the exact same thing as on the target laptop - the same 3 dependencies are "wrong CPU type", yet the application runs here.
I do not see an option in VS to change the "setup" project to read the 64 bit filepath. I have tried manually swapping in the 64-bit DLLs at various stages (including restarting the computer between DLL swap and application run), which did not seem to have any effect. In fact, I tried replacing the 3 relevant DLLs in the System32 folder with the DLLs from the SysWOW64 folder (my idea of a cheap workaround for not being able to change the filepath - just change the file) and this just caused me to get the same error on my source laptop as I had been getting on my target laptop.
All of this stuff is relatively new to me, so please let me know if I'm foolishly overlooking some fundamental detail with my process/project - at this point it would be nice if that were the case and this is easy to fix.
Wrote this before I noticed the above comment had already answered.
Just leaving it in.
Debug Binary: Looks like you have deployed a debug version of your binary (The D in the file name: MSVCP140D.dll). Try to compile in Release mode and deploy the new binary.
Cause: Debug binaries generally need the debug-versions of the VCRedist binaries to exist on the box you try to run the binary - they are only available on developer PCs with the SDK (and / or Visual Studio) installed. That error message: 0xc000007b means "STATUS_INVALID_IMAGE_FORMAT".
Tips: There are some resource links here and some tips on how to debug deployment problems.