When starting the debugger, Visual Studio just hangs for about 20 seconds, then terminates the debugging session, without any warning.
The 32-bit version works fine, but is no good if our plugin uses 64-bit native code from a third party.
As a developer, I'm sticking with Petrel 2012.1 on my workstation for the time being - might the issue be fixed in a later release?
It's not a bug but a feature – the license protection mechanism. But you can attach your debugger to Petrel 2012.1 64 bit when Petrel's UI is visible, the initial steps only are protected from debugging.
But of course you would still need to use 32-bit version of Petrel if you want edit-and-continue while debugging: Why doesn't Edit and Continue work on the x64 CLR?
Related
Im developing continually an inventor Addin in VB.Net in visual studio 2019 ,
i have multiple machine different builds , but once in a while some machine just don't want to load the Addin f.e. the current version i have now works on all machines except one AMD machine .
When i compile the same project with the same settings no changes at all on the AMD machine with ANY CPU build option it runs without problem . When i do it on my primary developing machine it does not work on this other computer.
I checked dependencies with dependency walker , i do not get any error messages .
When i make breakpoints in DEBUG mode and debug dll compilation in the first methods called in the "StandardAddInServer.vb" file it does not reach it on the AMD machine when it is compiled on the Intel machine. But in reverse it runs smoothly .
I have no idea what this could be and I'm only speculating that is has to do with AMD/Intel difference of the machines . Any help would be appreciated to come to a solution.
Inventor 2018.3.7 Professional Build 287 is on the Intel i7-4771 machine Visual Studio Community 2019 16.3.9 , .NET 4.8.03761
Inventor 2018 Professional build 112 is on the AMD Ryzen 7 3700X machine Visual Studio Community 2019 16.7.2 .NET 4.8.03752
Any more information which could be helpful will be provided gladly .
Well.... i tought lets make the maschines identical in regards to software .. i started installing inventor updates one by one at Version 2018.3.1 the Addin magically was working .... so i hope i help somebody if the , addin automatically unloads without any error , its probably autodesk inventors fault ...
Are you using ANY CPU ,or are you forcing the project to a given bit size?
If you don't set this, and leave it at ANY CPU? Well, if you launch the application from Visual Studio (such as installing on that target machine), then the application will run as x32 bits.
HOWEVER if you launch the program from the windows command line (command prompt).
Well, if you use the x64 bit command prompt, you get a x64 bit running - in-process program. If any of your external .dll's or libraryes are x32 (or not compiled with ANY cpu), or you using any un-manage code libraies (say like ghostscript or some such)? Then your program will run (or try to) as x64 bits.
However, if you launch a x32 bit windows command prompt (there are two of them - one is x32, and one is x64). So, if you launch the .net exe (your program) from a windows x32 bit prompt, then your program will run in-process as x32 bits.
So, be careful here. Using ANY CPU from Visual Studio will ALWAYS get you a x32 bit program - including debugging. But RUNNING the program (launching outside of VS) will not always be x32 bits.
And the above behaviours seems to explain your issues/problems on the AMD machine. It was NOT that you installed VS on that machine, but that using VS to launch your program in fact FORCED it to run as x32 bits.
Bottom line:
do NOT use ANY CPU unless that is exactly what you need, and that you are VERY sure any external libraries are also compiled as ANY CPU, or in fact that any external libraries doe NOT USE any un-managed code.
All in all? I would config your project to force run as x86 ALWAYS, and thus you not get some surprises of code not working.
I doubt very much that the AMD CPU is the issue, and installing VS only worked because of forcing your project to run as x32 as opposed to x64 bits. It has zero to do with AMD here.
You could try with a former framework version like 4.6.2. That should fix the problem. It could be that the newer service packs of Inventor can deal with addins created with newer .net versions. When 2018 Inventor was released, .net 4.8 was not available.
Was Albert wrote is true as well. If the architecture of your dll doesn't meet that of your host process, it can't be loaded. A 64bit process can use 64bit dlls only whereas a 32bit one can deal with 32bit dll only. A .Net project won't be compiled by Studio into fully functional machine code (nowadays you can do this as well), but intermediate code only, which will be compiled finally by the .net framework on the target machine. If anyCPU is selected, you don't have to provide different versions for different hardware because of this behaviour.
I am developing a VB.Net based Windows8.1(10) Store application.
After published, I've found out that my App crashes on Windows8.1 while it works fine on Windows10.
So, I want to debug my App on the Windows8.1. However, I cannot find how to do so.
When I [Run] the App to [Simulator], it runs on clone of my computer, but I want to run it on other version of Windows.
Visual Studio 2015 is now installed on Windows10.
Thanks.
Disclaimer: I work on Visual Studio, though not on the Universal/Modern App area.
This is not a supported scenario and there is no feature present in Windows that emulates or simulates previous versions of the "Modern" runtime environment.
The Simulator feature is actually a local-loopback Remote Desktop (Terminal Services) session and existed to make it easier to debug Modern applications given that they could only run in a fullscreen mode, however as this is no-longer the case (as apps are now floating windows) the utility of the Simulator is limited, and as you're discovering is not relevant to your problem.
The only solution I can recommend is to use Hyper-V (or another desktop virtualisation product, such as VirtualBox or VMWare if you don't want a hypervisor installed) to install a dedicated Windows 8.1 environment followed by installing the Visual Studio Remote Debugger.
Given the rapid adoption of Windows 10 (as it is provided as a recommended update to the majority of Windows 8.1 users) I don't personally recommend explicitly targeting the Windows 8.x "Modern" app environment unless you know you will have users or if it's a contract requirement.
I would like to run a .exe file made with visual studio 2003 but I get an error every time I run it on a windows 7 machine, vista machine, and xp machine. The error on Windows 7 and vista says "application has stopped working" and then makes me close the error box.
In windows xp it's a little different error, "the application failed to operate (0xc0000135) Click on OK to terminate the application."
That error code seems to indicate the application failed to initialize correctly.
It is possible that the anticipated .NET version is not present.
As far as I know, VS 2003 by default compiles against the .NET 1.1 library. There is no straightforward way of installing this on a Windows 7 or Vista box. Do you need to compile it against the .NET 1.1 library, or can you load it in VS2005, change the output .net version to 2.0 or higher, and recompile the application?
If you have the source code to the application, try running the application in debug mode and stepping through line by line until you find the exception. If you do not have the source code, possibly try running the application in a couple different compatibility modes. Another option to try is to check the windows event log for anything more specific.
If you want to get really deep into it, you can use SysInternals ProcMon.exe and filter on the failing exe to view the WinAPI calls that are happening during the failure.
Also, a basic search of forums shows that error is usually accompanied with framework issues. Either recompile the application or check out what your required framework is in the VS2003 project settings.
Have been reading a lot about this one and the picture just gets muddier. I have a 32-bit app that installs a KeyboardHook to wait for a global hotkey and wake up. Running it on Win 7 x64 edition I notice it hangs Outlook x64 edition when the hotkey is pressed.
So I did some research and it looks like 32-bit keyboard hooks aren't even supposed to work in 64 bit apps. Time for more testing...
They hotkey works fine in 64-bit notepad, wordpad, and sticky notes. I verified that these are 64-bit apps since they don't have "*32" next to them in Task Manager. Doesn't hang the app and it does what it's supposed to. But wait... a 32-bit hook dll can't be loaded into a 64-bit app, right?
A look at Process Explorer shows the hook dll isn't even loaded into the notepad process! (If I run the 32-bit notepad.exe from WOW64 directory, I can see the dll loaded into the process, so I know I'm using the tools right).
So the Outlook hanging issue might or might not be related, but why is the hook even working at all in 64-bit notepad?
I have a 32-bit app that installs a KeyboardHook to wait for a global hotkey and wake up.
If that's your ultimate goal, then it's simpler and less of an impact on the system to just use RegisterHotKey.
I have activex server exe that was building and registering fine on 32bit OS. I wanted to make 64 bit version of that exe by upgrading project to Visual Studio 2010 and changing platform to X64 which apparently doesn't work.
Application itself works but I don't see it registered after running
That.exe /RegServer
I would appreciate any usable advice on migrating activex from 32 to x64.
Code that is processing /RegServer param is below:
if(lstrcmpi(lpszToken, _T("RegServer")) == 0)
{
_Module.UpdateRegistryFromResource(IDR_OUTDISKSARG, TRUE);
nRet = _Module.RegisterServer(TRUE);
bRun = false;
break;
}
32 bit activex is unuable for me since I have to load it in x64 .NET process.
Assuming that the process has enough rights to write to the registry, you'll have to take care of that by running it from an elevated command prompt, this is likely to only add the COM registry keys to the registry view that 64-bit processes can see.
32-bit COM clients get a different view of the registry, HKLM\Software\Wow6432Node. It is not going to find the registry keys there. Review RegCreateKeyEx() in the SDK docs. Note the link at the bottom and the talk about the KEY_WOW64_32KEY option. The online article is here.
32-bit clients accessing a 64-bit out-of-process COM server is otherwise a pretty well supported scenario, with some caveats. Like building and registering both the 32-bit and 64-bit proxy/stub DLLs.
When you run That.exe /RegServer, did you do that from an Administrator command prompt? If not that's probably why it didn't work.
If you did and it still didn't work, try debugging it to see what it's doing to the registry. e.g. Use Process Monitor, or even the Visual Studio debugger (remembering to ensure the debugger runs your app as admin).