Hi everyone,

• The first one is if the server you are connecting through Service Studio is running a Web Garden in IIS (multiple worker processes for one Application Pool). The debugger will not work correctly with Web Garden since debug information is stored in the worker process memory and you have no guarantees that your requests will always be served by the same process.
  In systems where you want to debug you must turn off Web Garden in IIS (set number of Worker Processes per Application Pool to 1).
   
• Note that the above also happens if you are running your development environment in a farm setup (meaning - with multiple front-ends behind a load balancer). In these setups, if you cannot guarantee that one individual user will always connect to the same front-end; since all information on the debug session is kept in memory, it is not possible to debug.
  To use a farm setup for development, your load balancer must be set to redirect specific users to a front-end based on something immutable. It cannot be a session cookie (like it's usually done for runtime applications). Using the source IP may be possible if the end-user IP is visible by the load balancer.
  Alternatively, instead of using a load balancer, distribute users by the front-ends "manually": give them distinct servers to connect to, or use DNS load balancer so users in different areas of the company connect to different servers.
   
• Another one, also related to IIS, is if you are experiencing Application Pool Recycling events while you are in the middle of a debugging session. If a request that is being debugged is interrupted because of such an event, it is unpredictable what may happen to the debug session.
  To verify if Recycling events are happening you can check the Windows Event Viewer logs of your Platform Server. One common cause for these is a mis-configured set of Application Pool memory limits in IIS (with "maximum memory" settings too low). Verify that these Application Pool settings follow the recommendations made in the OutSystems Platform Server Installation Checklist, under the sections named "Tuning Internet Information Services" (you can access the Installation Checklist by running the Platform Server .Net installer, even if you don't go through the full installation process).

• When multiple developers are debugging the same eSpace Public Area concurrently. This sort of behavior is felt if the network setup (with proxies/routers in the way) makes the developers’ Service Studio debugging requests reach the development server with the same IP (for example, if a reverse proxy masks the original IP and all requests arrive at the application server as if they came from the proxy itself).
  In this scenario it is not possible for the OutSystems Platform do distinguish between each user and the outcome is undetermined (the user that made the request may not be the one to which the breakpoint hit is reported to), or not.
  If this is the case, you should revise your network setup to make sure that each individual developer's Service Studio reaches the Platform Server with a different IP. There is no other way around this limitation.