I'm working on a fairly customized version of NOPCommerce 3.10. I don't even know how this is possible, but I have cloned an existing NOP Commerce "discount requirement" plugin, changed all of the relevant pieces of code to reflect a new name, etc, and when I run NOP Commerce locally through the Visual Studio 2012 IDE and debugger, install and then attempt to use that discount requirement plugin, as soon as I select it from the discount requirement dropdown, my entire computer immediately crashes. Not the site. Not IIS. Not Visual Studio. The whole computer immediately just turns off. I've reproduced the same issue on 3 other developer workstations, so it's not something weird with my PC.
To make matters even more confusing, I published the site, including this plugin to our staging server, and not only does it not crash the server, or the site, but the plugin actually functions completely as expected without any perceivable issues.
EDIT: If I reboot in safe mode with networking, the issue goes away and the plugin works as expected. However, if I use selective boot, disabling all startup programs and all services except those that are required for networking and SQL server, the issue recurs. I'm not an IT guy, so I really don't know what's the difference between safe mode with networking and selective boot with all but networking services disabled, but clearly there is a significant difference as it pertains to this issue.
How is this even possible, and more importantly, what could be causing this and how do I go about finding and resolving the issue?
Edit 2: If I debug on any workstation that is not the same model as mine, it works fine. I believe I have narrowed the issue down to the Intel Integrated HD Graphics display device and/or driver. I've tried several different versions of the driver to no avail, so it seems like either the issue is with the device, or it is so obscure that it's never been identified or fixed by the manufacturer.
Related
For over a month now I've been experiencing problems with VS2017 on my home PC. I even tried submitting the feedback to Microsoft. There's more info about the problems I'm experiencing there.
The problem:
The gist of it is that VS is eating RAM like crazy. As soon as I start opening files, adding new files, using IntelliSense, building or (especially) debugging, the RAM usage skyrockets.
After that it's only a matter of time before the VS crashes and restarts without any error message. Though there are numerous error messages throughout these breif ~20min I have with each session.
Additional details I observed:
Doesn't happen with Python projects, as these don't have to be built constantly. It might be eventually happening if you debug a lot, but I didn't have the chance to check that because most of my Python coding is debugged on an external device
Size of the loaded solution doesn't matter;
UWP and WPF seem to crash the most. Console Projects take longer to crash.
Also affects .NET Core;
It doesn't matter which version of .NET Framework I use;
VS2015 worked perfectly, but I don't have it anymore after the format
What I already tried:
I reinstalled VS;
I refreshed Windows;
I reinstalled Windows;
I checked my drives and RAM for issues - none found;
I switched from Community to Enterprise;
I tried disabling extensions;
I applied some shady hotfix I found somewhere;
Finally, I installed Rider which seems to be the best solution as of now. It still lacks many important features, though.
Is there anything else I can do/try/check? Did anyone experience (and fix) a similar issue?
Cheers!
You get a System.OutOfMemoryException, this means your Visual Studio runs out of free virtual address space (4GB on 64 Bit Windows for the 32Bit Visual Studio because Visual Studio is configured to be large address aware and MS refuses to release VS as 64Bit program which would fix this issue).
To analyze the memory usage, you need to run WPRUI.exe (part of Windows Performance Toolkit (which gets installed by VS2017) for some scenarios, if not, install it on your own), select Reference Set (Note: expand the Resource Analysis entry first to see all options).
and click on Start. Capture the memory usage grow for some 100s of MB and click on Save.
Open the generated ETL with the analyzer (WPA.exe) and analyze what the process devenv.exe is doing.
Also zip the ETL + NGENPDB folder (important) as zip and attach it to your bug report so that Microsoft can analyze it.
I'm experiencing some problems while using the DocumentDB Emulator (v. 1.11.136.2).
I'm able to see the Explorer (https://localhost:8081/_explorer/index.html) but I cannot create any Database\Collection using either the Explorer and the SDK (I tried with the sample code provided by that page and my own code).
I always get:
{"readyState":4,"responseText":"{\"code\":\"ServiceUnavailable\",\"message\":\"Service is currently unavailable.\\r\\nActivityId: 9c9f56f8-91f9-4fad-b592-0c6bd5bbd300\"}","responseJSON":{"code":"ServiceUnavailable","message":"Service is currently unavailable.\r\nActivityId: 9c9f56f8-91f9-4fad-b592-0c6bd5bbd300"},
"status":503,
"statusText":"error"}
I'm running Windows 10. I already tried to restart the PC and reinstall the SDK\Emulator.
To fix this I had to perform a "Reset Data" on the Emulator.
This is probably due to some issue around updating from DocumentDb to Cosmo Db emulator.
Microsoft Support answer:
The failure is when the emulator tries to bring up the network stack.
We have seen this on some customer machines where 3rd network filter
drivers break some of the Windows networking APIs that we use.
Examples of these include drivers installed by Pulse Secure (or
Juniper network). I think we’ve also seen this type of failure with
some 3rd party antivirus products.
Typically uninstalling the 3rd party software should resolve the
issue.
I tried to change ConnectionMode to Gateway as
to
and it worked perfectly
I have been having problems with my Windows 10 (for example my localhost:8000). So I started looking for an answer, and it looks like the good old IIS is causing this issue, maybe because it's not enable in the turn Windows features on/off. SO in theory it should be a piece of cake right? Well when I click next I get the following message:
Windows couldn't complete the requested changes.
The function attempted to use a name that is reserved for use by another transaction. Error code: 0x80071A90
I read somewhere that it may be related to the .NET Framework, I have Framework 3.5 and 4.6 installed. I have tried all possible combinations, enable both of them, disable both, only one, everything! Not real information around regarding the Error code either.
Does it have something to do with the version of Windows that I have? Which is Windows Home. Is there any other way to make it work? Thank you in advance for your input.
As this is one of the first hits when you search for that error message posting solution here...
If you get this error when trying to "Turn Windows features on or off" in Windows 10 - make sure to disable Antivirus program.
Culprit for me was Avast.
To disable Avast right click on the icon in task-bar -> Avast shields control -> Disable until computer is restarted.
After Avast was disabled I had no problems with adding new features.
I was trying to debug a heap corruption issue in our app, and used appverifier, gflags and _CrtSetDbgFlag to try and track it down. now i've cleared the gflags, removed our app from app verifier and removed _CrtSetDbgFlag, yet on my computer now the app is horrendously slow (over 15 minutes just to start it up).
It doesn't matter how i run the app, even with visual studio closed and double clicking a release executable i get the same slow behavior.
Can anyone point me to what i may have screwed up on my machine to have this issue?
Thanks
I've solved the problem for myself by using system restore to go back to before i used gflags. I notice now that gflags does come with the warning:
Note Incorrect use of this tool can degrade system performance or prevent Windows from starting, requiring you to reinstall Windows.
So i probably should have been more careful.
If anyone has a better way to fix this than system restore, like a list of the registry entries that gflags changes and what they should be by default, that would still be very helpful.
I inherited a huge code base which was written to work on Windows XP. Now we would like to migrate to Windows 7. I do not know what is the proper way to go about this. What is the proper approach to do the above task? I did some googling on differences between XP and Windows 7 but I do not get any proper links which describe how the internals of 7 differ from XP. Any links will be appreciated.
Usually how do S/W developers migrate their code/apps written for one version of OS say Vista to Windows 7?
I sell an autoupdate solution (AutoUpdate+, minor plug) and so have lots of experience porting Windows apps to the latest releases, and yet still maintaining backwards compatibility. Porting from Windows XP to Windows 7 can be a big challenge (there should be almost no difference in a move from Windows Vista to Window 7).
Window XP doesn't care where your application exists, and hence programmers would dump both their application and support logic (log files, config files, user profiles etc.) into the same location under "C:\Program Files\". Take this application to Windows 7 and you'll start finding some unusual behaviors. For starters, you will notice that files seem to 'disappear'. Instead of a log file being modified under the common Program Files location, you may end up with multiple, and separate, copies for each user under "Compatibility / Program Files". Windows Vista/7 introduced file system virtualization, and will now create separate user instances of files to ensure to ensure that each user has their own secure copy.
Another problem you will encounter on Windows Vista, and to a lesser extent on Windows 7, is User Account Control (UAC) prompts. It's similar to the issue above, in that new security restrictions will now cause Windows Vista/7 to prompt the user for approval to proceed. The most noticeable area where this occurs is when you are tampering with executable files in sensitive directories, installing applications and drivers, and sometimes when trying to self-update an app (the abovementioned app actually works around these prompts with some smart logic).
So in short, security changes are the biggest difference between Windows XP and Windows Vista/7. Your best start is to separate application logic (binaries) from supporting logic, by putting the latter into user specific directories. Some apps may never be fixable and can be forced instead to work in Compatibility Mode or to launch always under the Admin account context --- poor workarounds, but may be suitable in your company.
Simon # http://AutoUpdatePlus.com
There are three parts to the migration. First, make it just plain work. This means fixing up hardcoded file paths (there's no more Documents and Settings), changing some of your save locations so you don't need to be elevated to work properly and don't rely on virtualization, changing some of your registry key locations for the same reason, and coping with high-DPI which might now be applied automatically based on screen size rather than as a user's choice.
Second, make it look and work like a Windows 7 application. Is your jumplist usable? Your thumbnail? You get some things for free, do you like what you get or would you like to take control? Are there obvious wins you could use like thumbnail buttons, jumplist tasks, taskbar overlays, etc. Don't surprise your users and don't disappoint your users. (Example of disappointment: VS 2008 and the crummy jumplists it offered. They had the excuse of being released before Windows 7 - you don't.)
Third, take advantage of Windows 7 to be greater than you otherwise would. Stop polling for network joins, file creation, hardware being plugged in, going on and off AC power etc and learn how to get notified when those things happen. Add touch support beyond what you get for free. Talk to a sensor or GPS for the first time, since Windows 7 makes it simpler than it ever was. That sort of thing.
1 is not optional. 2 is really not optional either, a year after Windows 7 is released. 3 will differentiate you and I recommend, once you get past 1 and 2, you look into it.
Basically Windows7 is a 4bit OS and so necessarily runs on a 64bit processor environment. XP has 32bit as well as 4 bit flavours. If your application is for the 32bit version of XP, in that case, the major migration means making the application run on 4bit OS effectively.
The basic steps can be something like this:
Make it compatible to 64bit win7. So you may just compile the code off a win7 machine (on 64bit). If the compilation works fine, you might be able to run the app successfully.
The first step just allows to move ahead. But your application might not be effective. In that case, you might have to review the code for any specific implementation coupled on 32bit os and upgrade them to take advantage of 64bit OS.
The major advantages on 64bit OS is higher address-ability (so access more RAM) and also cache etc.
I did some googling on differences between XP and Windows 7 but I do not get any proper links which describe how the internals of 7 differ from XP. Any links will be appreciated.
API diff report between XP and Vista: https://abi-laboratory.pro/compatibility/Windows_5.0_to_Windows_6.0/x86_64/abi_compat_report.html
API diff report between Vista and 7: https://abi-laboratory.pro/compatibility/Windows_6.0_to_Windows_7.0/x86_64/abi_compat_report.html
The reports are generated by the abi-compliance-checker tool.