I have moved all my users from windows 7 machines to Windows Server 2008 remote desktop. All of the apps they use currently were developed in vb6 (new apps are being developed in c#.Net currently) and need to be used for the time being...
The apps seems to run fine in Windows 7. I just can't get them to play nice with server 2008. I did try to run dependency walker and found it was missing "msvbvm60.dll". Tracked that down to the actual VB6 runtime. Tried to find a download for VB6 runtime for server 2008 x64 and that was a no go. So I just tried to put the "msvbvm60.dll" file inside c:\windows\system32\ and c:\windows\SysWOW64.
It said there was already a file named "msvbvm60.dll" in the SysWow64 folder. So my question is, why would it not work? It seems windows 2008 already has the runtime on the machine. But depends says that "msvbvm60.dll" is missing... :/
Ideas?
Solved!
The issue has to do with DEP!
The root cause of this problem is a change made in Windows Server 2008 R2 to the time when the tsappcmp.dll module (Remote Desktop Services Application Compatibility DLL) gets initialized, which consequently causes your application to call DLL functions before it establishes a link to functions within the DLL.
The way I solved it was very simple! I just excluded my application from the Data Execution Prevention process and it allowed the application and all it's dependencies to load up without faulting in a timely manner.
Usage:
rundll32 sysdm.cpl, NoExecuteAddFileOptOutList "FullPathToExecutable"
Example:
rundll32 sysdm.cpl, NoExecuteAddFileOptOutList "C:\Program Files (x86)\MyApplication\MyApplication.exe"
Sources:
Access Violation of BEX or APPCRASH occurrs on Windows Server 2008 R2 with Terminal Service
This is a wild guess but can you run them with Compatibility Mode? (right-click > Properties > Compatibility)
Related
I need to communicate with a legacy software wrote in Visual Basic 6 to launch a report (with output in pdf format) from a .net application (using full framework 4.5).
I have to istantiate an ActiveX COM Dll that internally use COM Crystal Report 11 runtime objects.
My .net application (which project target x86 platform) instantiate COM Dll "MyInterop.dll" which contains the class "Ambient" that runs the job..
do something like this (simplified code):
Type type = Type.GetTypeFromProgID("MyInterop.Ambient", true);
printerObj = Activator.CreateInstance(type);
printerObj.init();
printerObj.print();
If I run the application on a desktop system (in my case on Windows 8.1) everything works well!
If I move application on a Windows Server 2012 R2 (but I tried with a Windows Server 2016 too) it crashes!
I can not get a detailed error, I get "vshost32.exe has stopped working".
It's not easy to debug but It seems to crash when, in the code contained in the COM dll, attempt to read the report query string:
query = CRAXDRT.Report.SQLQueryString
(aobut CRAXDRT, I found on Dll Com Project a reference to
"Program Files (x86)\Common Files\Business Objects\3.0\bin\craxdrt.dll#Crystal Reports ActiveX Designer Run Time Library 11.0")
I cannot understand why, on a windows server system, the attempt to read the query string causes the application crash..
I do not know where to search information..
any suggestion is very welcome
Thanks in advance
Finally I found the solution:
1) first I have to modify exe binary of my .net application with this command (from VS cmd prompt):
editbin.exe /NXCOMPAT:NO [my binary path]
2) add the exe to the DEP exceptions (on Advanced System settings-> Performance option-> Data Execution Prevention)
Then it works!
I am new to .NET application.
I have developed the application on 32 bit OS with Visual Studio 2008.
The application required the Microsoft.Interop services and for PDF services to open PDF files and MS Office files.
It also required SQL Express for database operations.
The application works fine on 32bit OS.
Then I created the setup for 64 bit OS, I added a new Setup project with wizard in Visual
Studio 2010 and select the Primary output and Localized resources.
But it does not included the Resources folder to the Application folder.
I set the target machine 64x and build the project, also before building give the prerequisites to the project which is Windows Installer 3.1, and .net framework 4.0, I have used the .net framwork 3.5 in the application.
Then I ran the setup, which executed successfully.
But when I tried to run the application it gave the message "Application has stoped working. Finding for the solution from the web.." and it closed.
Then I saw that there was no resources folder so I just copied the resources folder to the application where it was installed. Then the application worked fine.
So I created the setup again but this time I also provided the Resources folder to the application folder. Built the Setup and tried to run the application but the same message is prompted to me as it was giving before "Application has stopped working...", so I looked for the resource folder and all the required files which were there.
Creating a separate 64-bit version makes no sense in your case.
You have dependencies to 32-bit components; as a consequence, all1 your assemblies must be compiled to the x86 target platform and be installed using a 32-bit MSI.
If you get an "Application has stopped working..." error, this indicates that an exception occurred that has not been handled by your process. You can get the stack trace e.g. from the event log.
1 In fact, at the least the entry assembly must have an x86 target platform, and all other assemblies must have either an x86 or AnyCPU target platform.
Check you have changed the platform target to x64 or AnyCPU in your project -> Build Properties
hey friends thanks for answering my question. Finally doing a lot of things I found that it was converting the sql database to 2008 while creating the setup. And I was setting the sql express 2005 on the client machine. Then I changed the sql server 2005 to sql express 2008 and run the setup. Then I found that at the first time the exe required all the rights to convert so I tried the setup Run as Administrator and bingo the setup works for 2 different pc..
The only thing is required that at first time I need to run the application as Administrator.
Thanks for help I
I have added the Acrobat com object in my application and use it successfully while debugging under visual studio.net 2010 framework 3.5, but whenever I deployed my application in IIS 7 and tried to browse the application, I got the error unable to load Interop.Acrobat
please help
Regards
Ahsan
One potential reason is x86/x64 mismatch - VS test host is 32 bit only, but IIS defaults to x64 on x64 OS.
Note: you are likely to run into troubles by using client application from server side code. There could be better options if you actually state what you want to achieve instead of what you want trying to do.
When you deploy the application, you will need to copy the automatically created Interop dll that was created in your bin directory.
I am running into an issue when attempting to use MapPoint libraries within our C# .NET application from a published app on a Windows Server 2008 machine. When instantiating the MapPoint.MapClass, I get the error:
"Your registry settings for this application were not copied correctly. To correct these settings, run Setup again for this application from the location where you originally installed it."
I am able to launch MapPoint just fine by itself outside of the app, the error only comes up when running the published app. We have multiple servers that clients run the app on, and the server running Server 2003 is able to launch MapPoint just fine. In addition, XP and Win7 machines also work fine. We also have a Foxpro application that also utilizes MapPoint's API installed on the 2008 server, and it doesn't have any issues.
MapPoint is included as a COM reference in the VS project referring to "Microsoft MapPoint 13.0 Object Library (North America) 8.3".
Looking online, I found a bunch of possible solutions, but nothing worked. I have tried:
Uninstalling MapPoint 2006 entirely and manually removing all entries from the registry, then reinstalling
Doing the same as 1 but then installing the trial of MapPoint 2011, resulting in the exact same error message
Disabling UAC
Setting MapPoint.exe's compatibility mode to Server 2003 and XP
Please let me know if anyone has any other suggestions.
it does sound like something is partially installing / being blocked. Is this a user issue? Ie. Can you install for all users?
it doesn't explain the MP2006 issue, but I would avoid the trial version for API work - the trial nag screen can be a problem. Eg. If you start the app hidden, the user cannot always see the nag screen to dismiss it.
You say you are instantiating a Map class. What about the Application (or _Application) class: you must have one of these to create the Map.
I made C# application for my friend which has connection to access database (mdb file). I have developed application on my computer with win7 x86 installed. My friend had XP and it worked perfectly, but now he installed win7 x64 and application doesn't work. In fact, application starts and behave regular, but cannot connect to database... Database too can be opened with access, but my application cannot connect to it.
What can be a problem? How to make my application works on both operating systems?
regards,
Vajda
Ask your friend to download and install the following file:
Microsoft Access Database Engine 2010 Redistributable
and make sure he picks the 64-bit version there (AccessDatabaseEngine_x64.exe).
By default there is no 64-bit ODBC/OLEDB driver for Access installed, but the 2010 version should work for 2007 databases as well.
You could probably also configure your program to be built for the x86 target. That would run the program as a 32-bit program, even on 64-bit OS.
Most likely, the .Net CLR is trying to fire the app up in 64bit mode by default on his new win7 box and this might be causing some issues with the referenced assemblies.
The first thing I would try is to change the Platform target of the application (go to Project properties in Visual Studio for the application) to x86 (from Any CPU) to force the application to run in 32bit mode.
If this works, you will have narrowed down your problem.
Then, after building the project, look in the bin folder to see which assemblies are being copied to the output folder. If you see any System.Data... or any other .Net assemblies that are already contained in the GAC, you'll want to delete these and then try to fire it up. This will force the application to use GAC assemblies written for 64bit use.