-
Notifications
You must be signed in to change notification settings - Fork 584
iisnode faq
When installing for IIS 7.x, please choose x86 flavors for installation on 32-bit Windows systems, and amd64 flavors for installation on 64-bit Windows systems.
When installing for IIS Express, please choose x86 flavor regardless of the bitness of your OS (IIS Express only ships 32 bit version currently).
iisnode is completely async and does not block threads per request or connection. It does allocate small amounts of memory for active requests.
Please verify if your issue is already known by searching https://github.com/tjanczuk/iisnode/issues. If you don't find it there, create a new issue report. Please include the following information with your bug report:
- Windows OS version and bitness (32/64)
- IIS version
- which version of iisnode you are using (changelist number if compiled, binary package name if downloaded)
- all interesting information from the IIS error page that displays (if any)
- all interesting information IIS logs into the Event Viewer (http://msdn.microsoft.com/en-us/library/ms524984(v=vs.90).aspx)
If you run into a 503 status code with IIS reporting error code 0x5 (ERROR_ACCESS_DENIED), make sure the identity of the application pool running the site that hosts your node.js application has read & execute rights to node.exe on disk. If you are using the default IIS configuration (DefaultAppPool running under ApplicationPoolIdentity), you can set appropriate ACLs on the node.exe by running:
icacls %systemdrive%\node\node.exe /grant IIS_IUSRS:rx
- open iisnode.sln in Visual Studio Pro, Premium, or Ultimate
- open Configuration Manager and choose Debug configuration with either Win32 or x64 Platform, depending on your OS
- iisreset
- rebuild solution
- call
build\debug\%PROCESSOR_ARCHITECTURE%\iisnode.msi
from an administrative command line - open web browser and navigate to the root of the virtual directory of the node.js application you want to debug; alternatively, you can access a static file (e.g. HTML) in that location. For example, navigate to http://localhost/node/helloworld/readme.htm to debug the helloworld sample. This step is meant to create w3wp.exe you will attach to next
- back in Visual Studio, attach to the w3wp.exe process: Debug|Attach to process; make sure native code debugging is selected; if you don't see w3wp.exe, make sure "Show processes from all users" and "Show processes in all sessions" is selected
- make sure symbols for iisnode.dll were properly loaded by going to Debug|Windows|Modules
- put your breakpoints in; here are some places of interest:
- CNodeHttpModule::OnExecuteRequestHandler - beginning of HTTP request processing
- CNodeApplication::Initialize - called on first access to a particular *.js node application in a vroot
- CNodeApplicationManager::GetOrCreateNodeApplication - called on every request to determine which application to dispatch the HTTP request to
- CNodeProcessManager::TryDispatchOneRequest - called to pick up an HTTP request pending for processing by a particular node.js application and dispatch it for processing by a particular node.exe process
- CNodeProcess::Initialize - called whenever a new instance of a node.exe process is created
- CProtocolBridge::SendEmptyResponse - called whenever an error occurs during processing and an attempt is made to gracefully return an HTTP error back to the client; great way to capture things going badly
- CProtocolBridge::FinalizeResponse - called on successful completion of HTTP request processing
- go back to the browser, issue a request to your node.js app (e.g. http://localhost/node/helloworld/hello.js); your breakpoints in VS should be hit.