We ran in the following problem in our system.
We have several reports, built with Stimulsoft. Reports use SQL Server as datasource (instead of stored procedures, SQL code is provided inside scripts).
When we run sql scripts in management studio - each of them runs in 3-5 sec. When then stimulsoft builds report, it takes 20 seconds. That's fine - because reports are cross-tab reports, and it is supposed to be a lot of calculations.
We use Windows server 2008 R2 64-bit. IIS process w3wp.exe runs in 32-bit mode. When we run 10 different reports, each of them increase memory usage of w3wp.exe by 300-400 M. And when it reaches almost 2Gb, the following reports stop to execute.
Any idea how to say w3wp to run as 64-bit process?
Launch IIS Manager and select the Application Pools node. Right click on the specific application pool that your site/application resides in and select "Advanced Settings". There'll be a setting under "General" labelled "Enabled 32-Bit Applications":
Set this value to "True" for to run w3wp.exe as a 32 bit process or "False" to run as a 64 bit process.
Related
I've been working on creating reproducible development virtual machines for my team's work on Xperience CMS with the Hashicorp Vagrant tool. In this environment, the Xperience 13 administrative backend is encountering a runtime error upon startup, as can bee seen in the attached screenshot. I can confirm that the CMS connection string is correct because I have been able to successfully run an Xperience MVC Core site in the very same environment with the very same connection string. I have also used the exact same connection string to directly open a SQL connection using PowerShell in the exact same environment.
Things I have tried to diagnose the issue:
I have tried increasing the execution timeout to the maximum allowed value. The runtime error still occurs, and long before the timeout's default value of 2400 seconds.
I have tried attaching the Visual Studio debugger. The debugger reported "'CMS.DataEngine.ApplicationInitException' in CMS.DataEngine.dll" but no further details or stack trace.
I have confirmed the correct firewall passthrough rules are in place.
I have completely turned off Windows Firewall.
The environment is running on Hyper-V inside a Windows 10 host. The guest development environment has the following specs:
Windows 11 Pro 21H2
16GB RAM
200GB Virtual Drive
11th Gen Intel(R) Core(TM) i7-11800H # 2.30GHz 2.30 GHz - 4 virtual processors
SQL Server 2019
All required IIS features enabled for XperienceCMS
.NET Framework 4.8
Kentico Xperience CMS 13 Hotfix 47
I'm running out of ideas to diagnose this problem.
It was an NTFS folder permissions issue on inetpub\wwwroot that either wasn't being applied or wasn't being propagated down the hierarchy. IIS_IUSRS needed Modify permissions. Setting then resetting Modify, Read, and Execute permissions and propagating them down to subfolders and files solved the issue.
I'm trying to debug an ASPNET Core/EF Core website hosted on Azure. When I try to attach the debugger in VS 2015, via Cloud Explorer, I get this error message:
Yet when I check the site in the Azure portal, it sure seems like it's 32 bit and set to enable remote debugging:
So what am I missing or doing wrong?
Portal setting controls the bitness of the IIS w3wp process. But ASP.NET Core runs in its own process, so that setting has no effect on it. Instead, what determines whether your .NET Core process runs as 32 or 64 bit is how you publish it.
Given that apparently your Core project is published as 64 bit, you might want to try switching the Portal setting to 64 bit. This will affect the debugger MSVCMON.exe process, which should then allow you to attach.
We have a legacy application that has been running successfully for many years. It is a VB 6 activex component that we use to call a dll written with C. The vb component is called by a vb (desktop) application and is also called using classic asp. This setup has worked for many years and runs on a windows 2003 development server (IIS 6) and a windows 2008 R2 live server (IIS 7.5).
We place the dll in the system32 directory on 2003 and in the syswow64 direction on 2008.
The active x dll gets registered as follows:
regsvr32 c:\windows\system32\wrapper.dll
Recently, we are running into what appears to be some type of memory issue. The problem does NOT show itself in the desktop app. The problem only appears when running from classic asp under IIS.
When the application fails, it does not throw any type of error. But, the values in an array within the C program never get populated. Thus, the results from the dll are incomplete.
Some recent changes to the C dll have started to cause problems. In C, we have discovered that a value of 1500 for this array, causes it to fail.
#define PPT_LIST_LENGTH 1400
float f_list[PPT_LIST_LENGTH];
double d_list[PPT_LIST_LENGTH];
With 1400 it runs under IIS, but, the past few days, we have noticed that it will start to fail after running on the live server for a couple days. If I reset IIS, the application begins to run normally again.
This last problem seems to confirm that it is some type of memory issue.
Are there any settings in IIS that might give the application more memory? A way to give the dll more memory from the vb component? Ideas?
I am doing PHP development in Visual Studio, and my solution contains projects for PHP, SSRS, and SQL Server (SSDT). And I am using TFS for version control. So there's a lot going on in my dev environment that can "go wrong".
I am experiencing intermittent hangs, usually around 5 minutes a clip. Visual Studio gives me the wait cursor, and if I click anywhere in VS the window dims. And then I just have to wait it out. Sometimes I can end the devenv.exe task, other times it takes several minutes to terminate the task. If I am feeling patient, I just wait and eventually (around 5 mins) VS comes back to life. I've never experienced loss of data, source control issues, etc, even when I terminate the process.
It happens sometimes when I save. Sometimes when I check-in. Sometimes when I check out. Sometimes when I build. I have been unable to discern any sort of pattern of the behavior.
All my workstation resources are fine- no RAM or i/o or network or CPU issues.
What can I do to troubleshoot this issue? Can I run VS in some sort of logging mode that would allow me to pinpoint what is taking so long during these periods of lockup?
To turn on logging in visual studio, run: devenv.exe /log
I personally would do this with a shortcut.
Consider deleting old TFS Workspace definitions left over from Continuous Integration Builds.
We had this same problem with a large Team Foundation Server project tree.
Sometimes, but not always, opening a Solution in Visual Studio 2010 or Visual Studio 2012 would hang exactly as described above. VS 2010 was most vulnerable; VS 2012 seemed less vulnerable, but it still would hang.
We were able to get some clues by monitoring the server activity on the TFS Server machine and the underlying SQL Server machine. A certain query stored procedure was using excessive CPU time in SQL Server. We tracked this stored procedure name to a TFS operation involved in scanning TFS Workspace definitions for other user's checkouts for files.
Our TFS environment has been in use for over 3 years, and we have been using Continuous Integration build definitions using a "zombie army" of developer workstations as TFS Build Agent hosts. We also create new TFS Branches for major releases. Each branch contains about 20 separate Visual Studio Solutions with their own build definitions.
Over time, we had accumulated about 2,000 TFS Workspace definitions on each developer workstation. We had about 10 workstations at one time with their own definitions.
Using the Visual Studio Command window and running as a TFS Administrator, we used this command to identify all workspaces created by our "build user":
tf workspaces /collection:tfservername\collectionname /owner:ourbuilduser >c:\tf_ws_del.bat
We then used global substitutes and the Notepad++ editor macro recorder to convert each result line into this form:
tf workspace /delete /collection:tfservername\collectionname workspacename;ourbuilduser <c:\yes.txt
where C:\yes.txt contained a single line of "y"
We also used some human judgement to remove deletion lines for workspaces named for our most recent TFS branch.
We then ran that c:\tfs_ws_del.bat script in the same Visual Studio Command window and waited patiently for it to finish.
End Result: Our Visual Studio solutions open very quickly. Even browsing the folder hierarchy in Source Control Explorer has sped up considerably.
WARNING: The deletion operations for a very large number of workspaces may expand the TempDB on the underlying SQL Server by a large amount. Coordinate with your DBA's to monitor space on the SQL Server machine. Stopping and restarting the TFS Collection via the graphical TFS Administrator Console tool helps reclaim some of that TempDB space and return it to its internal "free block" list.
This can also seem to happen when the symbol servers specified in your debug options are down or unreachable... it will not actually hang in this case but seem to as it times out for each file access.
To temporarily get around this problem uncheck the symbol servers that are down.
I have inherited a classic ASP project and a VB6 Component (ActiveX .dll) that goes with it.
I would like to be able to debug this component by running it locally on my machine.
I have a Windows 7 Home Premium (64 bit) laptop.
I have setup IIS 7.5 locally (production is running IIS5), however, when I browse to the site (locally) I get:
Active Server Pages error '00000000'
Create object failed
?
An error occured while create object 'OBJECTNAME'
Microsoft VBScript runtime error '800a01ae'
Class does't support Automation: 'ID of object in global.asa
I'm not a server guy, so I don't have a lot of experience setting up IIS. I want to setup this project locally so I can step through the COM object using the debugger.
What do I need to do to get this running?
Just as an FYI :
In the global.asa I have the following:
<object runat="server" scope="session" id="ABC" progid="prjABC.clsABC"></object>
Then in the ASP I have the following call:
if ABC.propertyName = True then
...
It fails at that line.
Sounds like the application pool your site is running in is configured for 64-bit mode (the default).
Switch it to 32-bit by right clicking on the pool and choosing Advanced Settings:
Set Enable 32-Bit Applications to True.
You might also want to configure the Managed Pipeline Mode and set that to Classic, not all Classic ASP apps are happy running in Integrated mode.
If all you need to do is debug the component it may be easier writing a COM Application that uses this COM component. Especially if you have the source to the component you can launch your test application from your vb6 component project as your debug application.
Since it's VB6 though you may have to set up a XP virtual machine to be able to run visual studio 6.0 (I've never been able to get 6.0 working on windows 7). Either that or upgrade the component to visual studio 2010.
If you want to run 32 bit components in a 64 bit environment, you can do it. The trouble with setting IIS to allow running 32 bit components as described above is that you end up having all of iis running 32 bit - which if it's a webserver means the main app you're running is 32 bit so reduces the speed advantage of a 64 bit machine.
To run a 32 bit component in a 64 bit IIS, you need to put it in Component Services. Start->Run->"comexp.msc" runs component services. Then just expand down the tree until you find COM+ Applications, and create a new empty application (with all the defaults set as are). Then expand that application and right click on components and then "new">component. The install new component and select the DLLs. This should allow a 64 bit component to just use the 32 bit ones.