Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Tuesday, December 31, 2019 12:11 AM
I upgraded from Visual Studio 17 to 19 some time ago. Now I just noticed that Task Manager identifies VS 19 as a 32-bit application. I'm running Win8.1 on a 64-bit processor. When you download an update to VS it doesn't provide a selection of 32 vs 64 bit. Now I'm wondering if problems I've been experiencing with VS may be because of it being the wrong version.
All replies (7)
Tuesday, December 31, 2019 2:39 AM âś…Answered
Hi Stupinls,
Welcome to MSDN forum.
>> Now I'm wondering if problems I've been experiencing with VS may be because of it being the wrong version.
## As I know, Visual Studio IDE is 32bit because of many existing extensions and the long history of Visual Studio. So the Task Manager identifies Visual Studio 2019 as a 32bit application, which is not caused by the wrong version.
In addition, if you want to learn more details about why the Visual Studio IDE is not 64bit, I suggest you could refer to the link.
Hope it will help you and any feedback will be expected.
Best Regards,
Anna
MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [email protected]
Tuesday, December 31, 2019 2:55 AM
Thanks so much Anna. The link explains it very well. What prompted me to even ask the question was that Visual Studio 19, in Debug Mode, froze and I got an out-of-memory error while simultaneously using PROCMon to find out where the error was occurring while trying to load an Excel Task Pane. I've got 4GB and I've ordered another 4GB for a total of 8GB and I hope that solves the problem. Thanks again.
Tuesday, December 31, 2019 9:57 AM
Hi Stupinls,
Thanks for your update and sorry for my delay reply.
Good to hear my reply is working.
But I am sorry to say that the principle of our forum is that a post only discusses one issue. So if you have other issue, I recommend you restart a new thread to ask for a better support, which will benefit to other community members who have the same issue. It will be easier for them to search the solution.
Thank you for helping us build a better Visual Studio.
Have a nice day!
Best Regards,
Anna
MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [email protected]
Tuesday, December 31, 2019 12:00 PM
Unfortunately this is a common misunderstanding.
Physical RAM is not the same as the process address space. The out of memory error is not saying that you have exhausted the physical memory in the system, it is saying that Visual Studio has exhausted the virtual address space. So extra memory will not fix this problem. You also have more than you realize because of virtual memory.
Do you see the committed value? This is the maximum amount of memory that my system can currently allocate, and yes it is about 10GiB larger than my physical memory. This is the value includes the page file. What's more, Windows is able to automatically resize the page file and can use up almost all of the hard disk space available on the system.
This situation would also occur on my development system, which has 64GiB RAM, because the problem is a process address space issue.
This out of memory situation is why the Visual C++ components moved the project system out into a separate process quite a while ago and in Visual Studio 2019 moved the debugger out into a separate process.
This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.
Tuesday, December 31, 2019 3:13 PM
Thank you Darran.
Tuesday, December 31, 2019 3:18 PM
Thank you Darran.
32 bits can address about 4GB of memory so any more memory will not be of any use.
n.Wright
Tuesday, December 31, 2019 7:11 PM
Again, remember that there is a difference between physical RAM and process address space.
There was never any mention of the operating system platform. Also, a 32 bit process can run on 64 bit Windows.
When a 32 bit process is running on 64 bit Windows, it actually has the same virtual address space limits as if was running on 32 bit versions of Windows. What this means is that even if you have enough physical RAM to push Windows 10 Pro to its limits (this is 2TiB), a 32 bit process will still give an out of memory error if you try to allocate more than 2GiB (~3.5GiB if large address aware has been set).
So a 32 bit process may not be able to address more than 4GiB of address space, but 64 bit Windows can. So having more than 4GiB of physical RAM in the system wouldn't actually hurt, it will improve the performance of Windows. But it will not fix the out of memory error since the Visual Studio process is exhausting the address space.
This has been a known problem for a while, people have been running into out of memory errors on 64 bit Windows for a while and it is becoming more common. This is why the release notes for Visual Studio 2019 lists:
"For C++ applications running on Windows, PDB now load in a separate 64-bit process. This change addresses a range of crashes caused by the debugger running out of memory when debugging applications that contain a large number of modules and PDBs."
So as already stated, this is nothing to do with physical RAM, this to do with Visual Studio being a 32 bit process and this is being exhausted.
This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.