Legacy 32-bit Inventory Client Failing on Monthly Report
A 40-user procurement office runs a legacy inventory client on one Windows 10 Pro desktop. The machine has an Intel Core i3-8100, 4 GB RAM, a 500 GB 7200 rpm HDD, and a 32-bit installation. The inventory database is 6 GB; the client loads a 1.8 GB index into memory when generating the monthly report. During report generation, Task Manager shows CPU at 22%, physical memory at 3.6 GB, commit charge 7.9 GB, disk active time 100%, and average disk queue length 6. The report takes 45 minutes and sometimes fails with 'out of memory'. The vendor says the application is certified only for 32-bit Windows. The office proposes buying a 1 TB SSD and doubling the page file to 16 GB. No other application is running during the report.
1. Identify the primary bottleneck and explain why the proposed SSD and larger page file will not fully solve the failure.
Read the worked answer
The machine is not CPU-bound: CPU is 22% while the report runs. Physical memory is 3.6 GB of 4 GB, commit charge is 7.9 GB, and disk active time is 100% with queue length 6. That pattern says the working set does not fit in RAM and Windows is paging heavily. The 1.8 GB index alone is close to the 2 GB user-mode address space that a 32-bit process typically receives, so the 'out of memory' error is an address-space failure, not just a shortage of physical RAM. A 1 TB SSD reduces paging latency and will make the machine feel better, but it cannot create address space. Doubling the page file to 16 GB raises the commit limit but not the 2 GB process limit, and it increases paging I/O. The primary bottleneck is the 32-bit process memory limit, with 4 GB RAM and the HDD as aggravating factors.
2. Recommend a migration path that keeps the vendor-supported application, with order of operations and a test.
Read the worked answer
First confirm with the vendor whether the client is large-address-aware or has a 64-bit build. A 32-bit application can run on 64-bit Windows under WoW64, but unless it is large-address-aware it still gets about 2 GB; if it is large-address-aware, it can use up to 4 GB on 64-bit Windows. Recommended order: image the PC; install 64-bit Windows 10 Pro, 16 GB RAM, and an SSD; install the vendor-supported client; test the monthly report on a copy of the 6 GB database; measure commit charge, hard page faults, disk queue, and report time. If the client remains limited to 2 GB, move it to a terminal server or remote-app host with more RAM, or ask the vendor for a 64-bit client. Do not simply enlarge the page file.
3. What measurements would prove the fix worked, and what would still require a vendor change?
Read the worked answer
Prove success by showing the report completes without an out-of-memory error; peak commit charge stays below physical RAM; hard page faults and disk queue length stay low (queue below about 2); and report time falls well below 45 minutes. In Process Explorer, check the process virtual size and whether it approaches the 2 GB or 4 GB limit. If the virtual size still hits that ceiling during a normal report, hardware alone has not fixed the problem and a vendor change, a 64-bit build, or a remote-app host is still required.