clustered index got disabled suddenly I have a large database with size of 40 GB and a one of the main tables which have row count of 3763071 rows and name of "XXX" and that table has a clustered index which is the primary key

suddenly that clustered index got disabled and the queries stopped

and i have a huge concurrent access on that table
And i have a full text index which got disabled too on the same table
and when i opened the logs found that the sql got some updates just before that problem. I am using dot net framework 4.5 and entity framework as ORM and sql server 2014 .so i'm asking what could cause that problem to avoid it again??
and one another question i have more than 25 index on that table 
so is it bad or good to have that number of indexes which have repeated columns?
I'm sure, by now, you've rebuilt your clustering index and your 25 non-clustered indexes as well.  While it might be difficult to determine why your clustering index got disabled in the first place, you could try implementing one or more server DDL triggers that would fire after an ALTER INDEX command and interrogate the command for the word 'disable' and roll the transaction back - (and wait for someone or some process to complain about that action).

Example here:

--DDL trigger to prevent index disable
USE [master]
GO
alter TRIGGER [xx_TestDisable] 
ON ALL SERVER 
FOR ALTER_INDEX as

declare @text nvarchar(max)

SET @text = EVENTDATA().value('(/EVENT_INSTANCE/TSQLCommand/CommandText)[1]','nvarchar(max)') 

if @text like '%disable%'
    rollback
GO

ENABLE TRIGGER [xx_TestDisable] ON ALL SERVER
GO

--Testing to see if the DDL trigger rolls back a disable
CREATE TABLE T (X INT CONSTRAINT IX_Index PRIMARY KEY);

ALTER INDEX IX_Index ON T DISABLE;

SELECT *
FROM T 


As far as your 25 indexes, I think I'll borrow a quote that is attributed to Albert Einstein (paraphrased) - “Everything should be made as simple as possible, but no simpler.”

If you 'need' 25 indexes, then you 'need' 25 indexes.

Only you can decide which indexes should be created and maintained, but you should definitely use sys.dm_db_index_usage_stats to see how active your indexes are. Here is a good start.