We have 64-bit Windows server and we need to explicitly enable the 32-bit mode in the Application Pool used by our web site, because the MS Jet Engine Data Provider used to import data from Excel does not run.
I am not sure, if we enable the 32-bit mode will we still get the advantage of 64-bit Server?
In IIS 7.x, there is a Advanced Settings property of the application pool called "Enable 32-bit Applications". If you run the application as a 32-bit applications it should be able to use 4 GB but obviously no more. So, in that respect, it can take advantage of running on a 64-bit server. On a 32-bit server (without special switches) it would only be able to use the 2GB of address space allocated to applications (the other 2 GB is presumed to be used by the OS).
ACE driver 64 bit is now available as a replacement of Jet driver. So you can use it instead,
http://blogs.msdn.com/b/psssql/archive/2010/01/21/how-to-get-a-x64-version-of-jet.aspx
(Read the last few paragraphs.)
Related
My web application is a web interface for a desktop application called MyApplication.exe. My web application is written in C# (MVC4) that communicates with the MyApplication.exe (written in delphi) via COM-Objects.
When 16 clients invoke the web app via the browser, 16 MyApplication.exe instances will be created on the server:
My Problem: if client number 17 invokes the web application, I get the following exception in my eventlog:
"System Error. Code: 8. Not enough storage is available to process this command."
The process explorer indicates, that the worker process w3wp.exe consumes ~600 MB memory, but the machine has 4 GB RAM.
Note: The created instances will be saved in sessions (inProc).
Im am Using:
MVC4
ASP.NET CLR 4.0
IIS 8
Windows Server 2012 R2 (also occurs on Windows 8.1)
4GB RAM
I tried the following things:
Create instances locally via a VB-Script using COM-Objects. Result: I am able to create ~50 instances of MyApplication.exe with no problems.
Adapted the machine.config using the following entry:
processModel enable="true" memoryLimit="100"
Result: After restarting the worker process, the problem still occurs.
Depending on the user IIS is running under this could be a problem where the non-interactive desktop heap size is an issue. I've ran into this problem involving windows services.
When you run your test application most likely you are running under a different user. You can try adjusting the non-interactive desktop heap size in the registry to see if it resolves this issue:
Below is taken from KB 126962
To correct this problem, increase the size of the desktop heap: Run
Registry Editor (Regedt32.exe). From the HKEY_LOCAL_MACHINE subtree,
go to the following key: \System\CurrentControlSet\Control\Session
Manager\SubSystems Select the Windows value. From the Edit menu,
choose String. Increase the SharedSection parameter.
For Windows NT: SharedSection specifies the system and desktop heaps
using the following format: SharedSection=xxxx,yyyy Add ",256" or
",512" after the yyyy number.
For Windows 2000, Windows XP, and Windows Server 2003: SharedSection
uses the following format to specify the system and desktop heaps:
SharedSection=xxxx,yyyy,zzzz For 32-bit operating systems, increase
the yyyy value to "12288"; Increase the zzzz value to "1024". For
64-bit operating systems, increase the yyyy value to "20480"; Increase
the zzzz value to "1024".
Here is also a similar article for windows vista / 7 KB 947246
I have referenced some 32 bit and some 64 bit DLL in my ASP.NET MVC 3 project.
The projects compile but I get runtime errors.
It's because I am running the web project as 64 bit.
How do I "enable 32 bit" in my local IIS (just how I can do it in IIS 7.5 Pro)?
I am using .NET 4.0
The error I get is:
Retrieving the COM class factory for component with CLSID {A6775dfd2-1dfF-421C-A187-4D55F4DDFBFF} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
If you don't require the 64 bit component (not sure what is running there or if this can be excluded as you simply wanted to know how to run in 32 bit more)
http://learn.iis.net/page.aspx/201/32-bit-mode-worker-processes/
You can set it at the server level via:
%windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.enable32BitAppOnWin64:true
Or set your particular app pool (more recommended imho) you can try the following. Sorry the page this came from is no longer seemingly active and only googles caches is showing it now:
Force IIS to create a 32-bit app pool worker process
If your application is running as a web app, meaning it is running in
an IIS app pool worker process, you’ll want that worker process
(w3wp.exe) to be a 32-bit process. That can be specified in the
advanced settings of the app pool:
Select the app pool for your web app. Click Advanced Settings… under
Edit Application Pool on the right. Change the value of Enable 32-Bit
Applications under (General) to True.
Note that the word “Enable” in the setting doesn’t mean “allow” as in
“allow either 32- or 64-bit applications.” It actually means “force”
as in “force the worker process to run in 32-bit mode so that 32-bit
applications are supported.” This means that the app pool worker
process will always be launched as a 32-bit process when this setting
has a value of True. Setting it to False will launch a 64-bit app
pool worker process.
Note that when an app pool worker process is started, it shows up in
the Image Name column on the Processes tab in Task Manager as
w3wp.exe. When the Enable 32-Bit Applications setting has a value of
True, it will be listed as w3wp.exe *32.
IIS Express 7.5 (as used by Visual Studio 2010 if you install it) is 32 bit only:
http://learn.iis.net/page.aspx/1265/iis-75-express-readme/
To quote:
Both 32-bit and 64-bit systems are supported, however only a 32-bit build of IIS 7.5 Express exists.
So I can't imagine that your problems would be related to the usual 32bit / 64bit pool mode issues that can arise if all of your DLL's are 32bit.
However if you're trying to load a 64 bit COM DLL then this will fail; 64 binaries can't be loaded into a 32 bit process and vice versa.
Another gotcha is forgetting to tick the Use IIS Express checkbox when choosing which web server to debug with:
If you don't tick that checkbox then you'll run your site in a child application in the DefaultWebSite on the version of IIS7 that ships with Windows.
The DefaultWebSite runs in the DefaultAppPool, which in 64 bit versions of Windows runs as a 64 bit process. So you need to change the DefaultAppPool to run as 32 bit if you want to use this instead and consume 32 bit binaries.
You need to do this using IIS7's MMC snap-in or by running the appcmd.exe tool from the command line.
Set your compile target to x86 instead of AnyCPU or x64. Your dll will always run in 32-bit without you needing to mess with the IIS server settings.
I have a web service which loads a 32-bit COM component. I am running this web service with IIS server in my local machine.
When I load the the test page from Visual Studio it succeeds, on the other hand, while loading it using IIS, it display following error
Retrieving the COM class factory for component XXX failed due to the following error: 80070005.
I tried changing the webservice's platform to x86 from Any CPU but that dint help. I am running this on Windows Server 2008 R2 - 64 bit.
I had to enable the 32-bit Applications from the Application Pools settings.
Check permissions on that COM. It may be that when you're running tests from VS, you're running as you (admin), while the user running the website's app-pool is totally different. That user needs to be added read+execute (or, activate, whatever) permissions for "local".
Maybe also see this: Retrieving the COM class factory for component error while generating word document
Sarat, this cannot be right. The "Enable 32-bit Applications" under Application Pools Defaults is not for running 32-bit applications or to solve your problem. It is there to enforce running 32-bit applications UNDER 32-bit processes only, which is not necessary in this case. Most 32-bit applications run fine on 64-bit processes. That's why you can run MS Office 2010 (which is still a 32-bit application) on Windows 7 64-bit machines.
You must have other settings tried and true after nearly a full year answering the original problem.
we are preparing for using windows x64 for our installations,but we are facing a problem about storing application settings(user and machines). Currently we store them in windows registry - HKLM and HKCU hives.
The problem is that there will possibly be both x86 apps and x64 apps,and x86 apps cannot access 64 bit registry. We could store everything in 32-bit registry (visible as wow64 in x64 app). Or we can store settings in a file -sqlite or sql server compact database to avoid concurrency hazards.
Do you have any advice? If yes,what is it? :)
32-bit apps can access the 64-bit registry. See the REGSAM argument of APIs like RegOpenKeyEx
Also note that only certain areas of the registry are partitioned so you may not have to do anything, depending on where things are stored.
As for whether you should use the registry or move to something completely different, that's quite an open-ended question. If you're happy with the registry other than this issue with 64-bit then I'd say stick with it and just use the REGSAM arguments to explicitly point to the 64-bit registry if and as required. (Or vice versa, make your 64-bit apps look in the 32-bit registry.)
I have an ASP.NET application that consumes a lot of memory. Therefore I want to use the Debug Diagnostic Tool to try to search if there might be a leak or something else.
In DebugDiag on the process tab I right click the w3wp.exe process and the only options I get are:
Terminate process
Copy
Only on some processes I get more options:
Monitor for leaks
Create full userdump
Why is this? Has it something to do with the identity of the worker process?
Can someone help me solve this so I can debug the worker process I am interested in?
Assuming you are are using DebugDiag 1.1. You need to use the correct version that matches the process architecture (there are 32bit and 64bit versions).
To check whether your application pool's worker process is 32bit or 64bit go to:
Control Panel -> Administrative Tools -> Internet Information Services (IIS) Manager
Don't open Internet Information Services (IIS) 6.0 Manager.
Open the Advanced Settings for your website (the link is on the Actions pane to the left). Note the Application Pool name then click Cancel.
Click on the Application Pools node on the left hand navigation tree pane and right click on the Application Pool noted above, select Advanced Settings.
If the application pool is 32bit then the setting Enable 32-bit Applications will be set to true, otherwise if false the pool will run in 64bit mode.
If the application pool is running in 64bit mode then you need to download and install the 64bit version of DebugDiag.
When you run 32 bit DebugDiag the column "32-Bit" on the processes tab will have "Yes" to indicate that a process is 32bit. Only these processes will have context menu options to 'Monitor For Leaks' and so on.
For more information see Tess Ferrandez's blog:
Capturing memory dumps for 32-bit processes on an x64 machine
If you can reproduce your suspected memory leak in 32bit mode then just switch the application pool to 32 bit and use the 32bit version of DebugDiag. Unfortunately both the 32bit and 64bit versions can't co-reside on the same machine.
Update:
DebugDiag 1.1 x64 only supports the
analysis features. There is a new
version in beta that does permit all
the functionality of the 32bit
version. Although not available
directly you can request a copy from
their support team, see the following
link for more info:
Debug Diag 1.2 (Beta)