I have a website that was running on 32 bit IIS 8.0. My website is built under "ANY CPU" configuration. Recently we had an issue where the memory was getting overflown. We wanted to run the website as a 64bit process so more memory becomes available to it.
I turned "Enable 32 bit application" to FALSE in IIS. When running the website I get the following error:
Enabling 32 bit as TRUE resolves the issue. Is there anything I have to do other than setting the app pool to use 64 bit to make the application run as a 64 bit process?
I found something similar here: stack overflow question but the Handler is different so I wanted to get some expert opinion on how to resolve this error.
I have developed a custom snmp extension agent to work in conjunction with Windows Snmp service. I have implemented in C++ using the interface provided by snmp.h from Microsoft and I am creating a 64 bit dll to be used as extension agent.
To install this dll as extension agent I have added a registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\ExtensionAgents as:
MyAgent REG_SZ SOFTWARE\MyAgent\CurrentVersion
And under HKEY_LOCAL_MACHINE\SOFTWARE\MyAgent\CurrentVersion, I have created another registry specifying the path of the dll as:
Pathname REG_EXPAND_SZ C:\Program Files\testing\MyAgent.dll
When I did this in the system event logs I keep getting that the The SNMP Service is ignoring extension agent dll C:\Program Files\testing\MyAgent.dll because it is missing or misconfigured.
The agent is a trapless agent. It exposes the SnmpExtensionInit and the SnmpExtensionQuery function from snmp.h. I don't know what is messed up. Do I need a 32 bit dll? All of the sources on internet are very old and refer to Windows NT. I need to configure it on newer operating systems like Windows 10 and Windows server 2016. Any suggestions would help.
Also there are similar questions on SO for same error but all of them are related to migration of a 32 bit dll. I am starting with 64 bit.
because the SNMP process is still 32-bit the key needs to be
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6232Node\MyAgent\CurrentVersion
but I am finding the SnmpExtensionInit is not called
My system has both 32-bit and 64-bit Redshift ODBC drivers installed. It shows up in the ODBC Data Sources under System DSN tab. However, only 32-bit driver shows up in the Drivers tab.
Also, when I attempt to make a Redshift connection by specifying 64-bit in the connection string Driver={Amazon Redshift (x64)}, I get this error: "ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified".
Only the following in the connection string seems to work Driver={Amazon Redshift (x86)}.
I tried
Re-installing and repairing 64-bit driver.
Removing 32-bit driver from the System DSN tab
But none seemed to work.
Am I missing something?
We had the same problem using the Amazon Redshift driver in our ASP.NET application at our company.
If you're also using the Amazon Redshift driver in an ASP.NET application, I hope what we figured out (the hard way) might help you.
The solution to the problem is to use the 64-bit driver if you're running the application with the 64-bit IIS, and to use the 32-bit driver if you're using the 32-bit IIS. The thing that caught us off guard is that even on a 64-bit machine running 64-bit Visual Studio, the default IIS is 32-bit, not 64-bit. (https://www.jc-tech.info/2016/09/24/running-32-bit-or-64-bit-iis-express/)
This explains why only the 32-bit driver is found by your application. Regarding why the 64-bit driver does not appear in the Drivers tab of the ODBC Data Sources Manager, there are actually 2 versions of the ODBC manager: a 32-bit version, and a 64-bit version. The 64-bit driver will only show up in the 64-bit ODBC manager.
When debugging your application, if you want to make sure that Visual Studio is using the 64-bit IIS, go to Tools>Options>Projects and Solutions>Web Projects, and tick the "Use the 64 bit version of IIS Express" checkbox.
Similarly, when you deploy your application, make sure that your driver version (32 or 64 bit) matches the version of your production environment.
Had same problem,
I kept only 32 bit driver and uninstalled 64-bit and I put
Driver={Amazon Redshift (x86)}.
It worked fine.
More info can be found from below link.
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/480db31c-b583-4c22-a7eb-bc37ad3a3e6d/data-source-name-not-found-and-no-default-driver-specified-error-in-report-builder-when-adding-an?forum=sqlreportingservices
If you are building a .NET application check the project properties for Build option to target x64 platform instead of using Any CPU option to target all
We have a 32 bit legacy multi-threaded C++ Windows Service that uses Msxml2.ServerXMLHTTP.3.0 instance to send a message to one or more remote computer/host/endpoint.
We recently migrated this service from a Windows 2008 Standard (32bit) OS to a Windows 2012 R2 64bit OS. The service still runs in 32bit mode.
What has been noticed is that things work fine if the remote host is online. However if the remote host goes offline then the memory and handle count grows uncontrollably till the service eventually crashes. If the remote host comes online or message is exchanged with any other host then the handle count and memory starts reducing back to normal and start going back up if any single host/endpoint (remote computer) goes offline.
What has been also noticed is that the IServerXMLHTTPRequest::Send() method timeout on Windows 2012 takes much longer (3-4 seconds) when compared to Windows 2008 (less than 200ms). The same service works fine on Windows 2008 64 bit but has issues with Windows 2012 R2.
Looking at netstat we see 2 SYN_SENT requests for the offline endpoint the first SYN_SENT state takes about 3-4 seconds to timeout. The same is much faster in 2008.
Any pointers would be much appreciated.
Thanks!!
Right now we are building a number of C++ apps for Win32 platform. We will be soon porting to Linux and then maybe more (32 and 64 bits for both).
What is the standard practice , do you use multiple hudson servers each on their own platform to do a build, or does the hudson service create VMs and do builds?
It is not clear to me the best practical way to do this.
Ideally I just want one box with a bunch of VMs running hudson, and then it kicks off builds as needed.
Is there a resource someone can point me to for this?
We use Hudson to manage C/C++ (GNU C, GNU C++, Watcom C) builds for multiple OSs. For us, software is built for Linux, Linux x64, QNX 4, and QNX6. The way we have it set up is:
1 x VM for the Hudson server, running Windows
4 x VMs, one for each slave type, so I have 4 Hudson slaves - 1 each for QNX4, QNX6 and Linux 32 and Linux 64. All of them are running on the same server, just as different VMs, and we have faced no problems. We build about a 100 projects, divided almost equally between the 4 system types.
You should not require any additional hardware. There is a Hudson plugin that works with VMWare VMs, to start them up and shut them down as required.
I hope that helps.
I've never used hudson for C++ but for what you are planning to do, it might make sense to look at the VMWare plugin and see if it will do what you want. I would recommend having only a single Hudson master if possible. What you most likely want to do is set up a VMWare machine image with a Hudson Slave process for each target environment then spawn a build in that Slave.
I have played with hudson in a multiple platform scenario a bit more than a year ago. I had one hudson server (which was ridiculously easy to setup) on some machine and separate build slaves for each of the platforms. I remember that for a while one of the build clients was in a VirtualBox on the machine that hosted the hudson server. (I think I had the server on a VM for a while, too.) I cannot remember there being any principle problem with this setup.
However, if you want to have several virtual build machines building on the same physical machine I think you'd need a very powerful machine for that. C++ compilation takes quite an amount of resources and, IIRC, when hudson starts a build, it starts it on all platforms at the same time.
Note that there need not be any relation between the server that's running Hudson and the slave machines that are building your software apps. Due to the magic of Java, you can connect the disparate slave machines to the master using JNLP. (one example) So, whether they are physical or virtual machines, you can have one running Windows, another Linux; one 32-bit, another 64-bit; etc -- whatever your apps require. As long as they all have the JRE installed they can connect to the Hudson master and report the status of the builds.