I'm not sure what documentation you've read so apologies if I'm repeating anything here.
To distribute reads to secondary nodes, most drivers allow you to set a readPreference value for the current session. Clients set read preference on a per-connection basis. With slaveOk, the driver should will always send queries to the secondaries, if they're available.
Distributing reads to secondaries requires the use of
ReplicaSetConnection with ReadPreference.SECONDARY.
See “rs.slaveOk()” for more information and this link.
In the mongo shell, to enable secondary reads, issue the following command :
rs.slaveOk()
The PHP documentation for it is here but I'm guessing that may be the documentation you're referring to.
As a FYI, here's an old discussion about it on the MongoDB Google Group.
If you're still having issues, I'd recommend using the MongoDB Google Group and providing some further information such as the version of MongoDB you're using, the version of the PHP driver, your log files, rs.conf() and rs.status().
As a FYI, you have to be careful with read scaling as sending too many reads to the secondaries can often result in the secondaries lagging the primary and becoming stale, thus requiring a full resync.
This is quite an involved question, but I will give a brief answer on each. You should try these out, then ask a more specific question (like give details about RAM availability and utilization, with working data set size to diagnose page faulting for example).
Un-expected shutdown resulting as corrupt collections
You don't list your full version, but make sure you are on a later version of 2.0 at least and preferably 2.2 (2.2.3 is in release candidate status as of writing this). There were multiple Windows related fixes later in the 2.0 branch and several of them dealt with making the Windows build less susceptible to hard crashes (which can lead to corruption).
MongoDB not releasing disk space for deleted objects (currently its around 28-GB and growing)
This has been covered in numerous other posts and discussions - see my answer here:
https://stackoverflow.com/questions/13390160/does-mongodb-reuse-deleted-space
Increased number of Page Faults
No control over data in RAM (unable to pre-load required data in RAM and remove after few minutes)
As mentioned above, page faulting and data fitting into RAM requires more details - how much data do you have, what is your working set size, do your indexes fit into memory etc. There are also numerous discussions on the mongodb-user Google group as well as Stack Overflow on this, and how to track this in MMS - a bit of searching for common approaches here is advised before you submit a new question. You should also note that page fault reporting in Windows can be tough to interpret thanks to the OS reporting "soft" page faults (already in memory but not owned/touched by a process) and "hard" page faults (actually paged from disk) in pretty much the same way.
A note about pre-loading, you can do this with the touch command in 2.2+, for indexes, data or both (see the linked page for options).
Frequent DB Errors like: Unable to read data from the transport connection...
Again, this will require logs, an idea of the relative load on the system etc. More detail definitely required - you could just be hitting a timeout or similar because you are overloading the DB. I would advise a separate question if these errors persist after you resolve other problems
Move MongoDB to Linux (provided that my .Net application using this DB will reside on Windows Server within same LAN)?
More people use MongoDB on Linux than Windows so it is more extensively tested and used by the community on that platform, but there is significant usage on Windows and large installations. Moving OS will not necessarily solve or automatically fix issues. If your data will not fit in RAM on Windows, it will likely not fit on Linux either for example, nor will it change how MongoDB reuses deleted space.
Setup a 2-servers replica set with Master on Windows and Slave on Linux ? OR
You should always run a replica set (minimum primary, slave, arbiter), regardless of the OS. It's just a good idea in general, but particularly if you are seeing some of the issues you describe. While in theory you can mix OS like you mention, I would recommend picking one or the other and just using that.
Best Answer
A replica set can only have one primary at any particular time (one master) with the other nodes being secondaries (slaves) and so they are nothing like master-master (i.e. multi-master) replication.
You definitely should move to a replica set from master/slave configuration because that is the preferred and recommended way to replicate. From MongoDB docs: "replica sets are a functional superset of master/slave, and newer, more robust code".
When a primary fails, one of the secondaries will be automatically elected as a new primary (you can see the docs to see the details of how that happens).
You cannot get write balancing from having a replica set - you can only distribute writes by sharding in MongoDB.